GLBP

Последний модуль, который будет посвящен протоколам класса FHRP, это будет модуль про GLBP. Протокол, который придумала Cisco, и который она продавала за достаточно большие деньги, потому что он действительно, по сравнению с другими протоколами, имеет ряд очень интересных преимуществ. По большому счету, GLBP — это тот же самый HSRP, только немножко продвинутый, прокачанный. Если говорить про HSRP, который мы с вами только что проходили, у HSRP есть две версии, первая и вторая. Мы с вами смотрели первую, но вторая, по большому счету, точно так же работает. Разница между первой и второй в том, что вторая еще IPv6 поддерживает. GLBP основан на HSRP второй версии. Там немножко другой формат пакета, но по большому счету очень похожее поведение будет на HSRP у GLBP. Точно так же GLBP будет выбирать активного и запасного соседа.

Но если говорить про HSRP, в HSRP у нас активный роутер forward-ил traffic, запасной сидел и ждал, пока тот сдохнет, а все остальные роутеры, если они были, сидели и ждали, пока сдохнет запасной. Поэтому, как следствие, в HSRP не было смысла объединять больше двух роутеров, потому что один роутер работал, второй сидел и ждал, пока тот сдохнет. Если вы соединяли в группу 10 роутеров, у вас один работал, один ждал, пока тот сдохнет, и 8 ждали, пока сдохнет запасной. По факту один работает из 10. GLBP — это протокол, который Cisco предложила для того, чтобы избавиться от проблемы, что деньги заплатили за два роутера, или за три, или за четыре, а по факту работает только один. GLBP выбирает активный роутер, но этот активный роутер не занимается forwarding-ом трафика сам. Это диспетчер, который назначает до четырех рабочих маршрутизаторов. В принципе, он сам тоже может работать. И поэтому по факту у вас будет не одна роль активного роутера, а четыре активных forwarder-а и один активный диспетчер.

Диспетчер будет называться AVG, Active Virtual Gateway, а forwarder-ы, которые занимаются forwarding-ом трафика, будут называться AVF. AVG выбирается, это полный аналог активного роутера в HSRP, а AVF назначаются. У каждого forwarder-а, AVF1, AVF2, AVF3, AVF4, будет свой собственный уникальный MAC, и для того, чтобы эти MAC-и раздавать клиентам, диспетчер будет их чередовать. Пришел один клиент, диспетчер сказал: ходи на MAC-адрес AVF1. Пришел другой клиент, диспетчер сказал: ходи на MAC-адрес AVF2. И получается таким образом, что у вас четыре роутера есть, допустим, в топологии, все четыре работают, все четыре forward-ят traffic. И есть клиенты, которые forward-ят traffic до каждого конкретного отдельного forwarder-а. Если вдруг какой-то forwarder выходит из строя, диспетчер это дело палит и немедленно говорит: окей, тогда кто-то другой будет занимать его должность. И кто-то другой либо поработает за двоих, либо, если у вас есть свободные желающие поработать,

кто-то из них получает роль forwarder-а, который отказал. Включается это с помощью тех же самых команд, которые мы видели для HSRP. Только если в HSRP у нас были команды, начинающиеся со standby, то в GLBP они будут начинаться на GLBP. Для того чтобы сказать, что у нас роутер будет участвовать в группе 1 и будет работать с виртуальным IP-адресом 10.0.0.254, мы указываем GLBP 1 IP 200.0.2.54. Можно указать гипотетически те же самые команды, которые мы использовали для управления HSRP. Это standby priority, standby preempt. В GLBP они тоже есть. Вы можете указать GLBP 1 priority, GLBP 1 preempt. Только эти команды будут указывать, кто должен с какой вероятностью стать активным диспетчером

и что будет, если вдруг у нас появится какой-то более достойный диспетчер. Диспетчер сам не испытывает никакой нагрузки. Для того чтобы диспетчерить, сильно умным быть не нужно. Поэтому, по большому счету, preempt в GLBP можно не включать, он там не нужен. Равно и приоритетами играть в GLBP тоже не нужно. Если у вас есть один роутер, который более мощный, и другой роутер, который менее мощный, абсолютно все равно, кто из них станет диспетчером. Прекрасно будет диспетчерить тот роутер, который менее мощный. Поэтому задачи играть приоритетами и задачи играть preempt-ом в GLBP нет. В HSRP это была очень важная задача, а в GLBP нет. Но в GLBP важная задача — играть весами. Дело в том, что если у вас есть роутеры, которые не одинаковые, например, есть один мощный роутер и один немощный, слабенький-маленький, который сидит просто на подхвате, и вы хотите, чтобы мощный роутер обслуживал много трафика, а запасной роутер обслуживал мало трафика, но все равно тоже не сидел без дела,

в этом случае вы можете назначить веса. Вы можете сказать, что некоторый роутер получает вес побольше, а некоторый поменьше. И тогда можно будет настроить AVG, которая отвечает разными MAC-адресами на запросы клиентов, чтобы ответы клиентам с разными MAC-адресами чередовались в определенной пропорции. Роутер, у которого вес больше, должен получить, соответственно, больше клиентов. На большее количество ARP-запросов мы должны отвечать его MAC-адресом. На роутер, который менее мощный, мы должны будем направлять меньшее количество клиентов. Это не означает, что то самое меньшее количество клиентов не сможет загрузить его по самые помидоры. Если у вас есть роутер, у которого будет вес 100, и роутер, у которого вес 10, один большой толстый с весом 100, и другой маленький с весом 10, это не означает, что AVG, которая будет раздавать MAC-и на эти роутеры,

не отдаст MAC-адрес вот этого 10-копеечного роутера одному клиенту, а 10 клиентов получат MAC-адрес большого роутера. Но этот один окажется настолько вредным, что он запустит торренты, и ему в 100% нагрузку упадет либо процессор, либо что-нибудь еще. А эти 10 будут сидеть ровно на попе, ничего не делать. Может такое произойти. И по факту мы играем не нагрузкой, а каким-то усредненным показателем, что при прочих равных, если все клиенты ведут себя одинаково, как будет гипотетически эта нагрузка распределяться. По факту, да, мы направляем разное количество клиентов на разные роутеры, и это никак напрямую не связано с тем, какая нагрузка по факту на эти роутеры ляжет. Но определенная корреляция там, конечно же, обычно есть. Если вы назначаете эти веса правильно,

то вы можете сказать, что при определенном поведении диспетчера разное количество клиентов будет приходить на разные forwarder-ы. Дальше. Так же, как и в случае с HSRP, есть команда show GLBP, которая покажет нам всю информацию, необходимую для диагностики этого протокола. Мы видим, что здесь сначала идет блок про диспетчера. Вот это AVG. Кто AVG, как он настроен. А дальше идет блок про forwarder-ов. Показывается, что за AVG у нас роль активная. То есть мы действительно сами диспетчеры. Показывается, какой у нас виртуальный MAC, показываются, какие таймеры. Все это видели, это все чисто HSRP-шные штуки. Показывается, что preempt выключен, показывается, кто активный, кто запасной. Показывается, какой приоритет у нас при выборах диспетчера.

Это не сильно интересно, потому что все равно, кто будет диспетчером. Но дальше начинается интересное. Здесь показывается, во-первых, какой метод балансировки мы используем при раздаче MAC-адресов клиентам. Если у нас есть два forwarder-а, то по умолчанию используется обычная каруселька. Приходит первый клиент, мы говорим: на тебе MAC-адрес первого forwarder-а. Приходит второй клиент, мы говорим: на тебе MAC-адрес второго forwarder-а. Приходит третий, мы снова даём первого. Приходит четвертый, мы снова даём второго. Никакой логики за тем, чтобы раздавать разным клиентам разные MAC-адреса в разных пропорциях, здесь нету. Просто обычная каруселька. Первый, второй, первый, второй, первый, второй. Показывается, кто вошел в группу. Диспетчер всех своих forwarder-ов знает наперечет и показывает, что два MAC-адреса с IP-шниками вот таким и вот таким будут, соответственно, входить в группу. Кстати, почему здесь MAC-адреса одинаковые? Я думаю, это какая-то ошибка.

Дальше. Показывается информация про первого forwarder-а и про второго. Максимум может быть четыре forwarder-а. Если роутеров в группе меньше, чем четыре, то количество ролей forwarder-ов будет столько, сколько роутеров у вас было. Если два роутера в группе, значит два forwarder-а будет. Если три роутера в группе, то три forwarder-а. Но если роутеров будет больше — пять, шесть, семь — то forwarder-ов все равно будет четыре. И вот forwarder первый. Мы знаем, кто он, потому что мы диспетчер. И мы так случайно выяснили, что это мы сами. Мы себе по блату выделили роль первого forwarder-а. А второй forwarder — это не мы. Мы слушаем от него hello-пакеты и ждем, пока он сдохнет. Если вдруг он сдохнет и некому будет передать его роль, кроме нас, то мы будем работать и за себя, и за него. Мы захватим роль второго forwarder-а и будем и диспетчером, и сами себе исполнителем.

Причем в двух лицах. Показывается по каждому forwarder-у виртуальный MAC-адрес, который он будет использовать. 0007b4 — это OUI HSRP второй версии. Дальше 0001 — это номер группы. И 01 — это номер forwarder-а. Для GLBP: 0007b4 — 0001 — 01. Это первая группа. 0007b4 — 0001 — 02. Это второй forwarder. Первая группа, второй forwarder. И если вы используете GLBP, то вы можете одновременно на нескольких роутерах обслуживать трафик ваших пользователей, которые находятся в одном широковещательном домене. Почему здесь написано HSRP? Кто-нибудь знает? GLBP. Использовать GLBP можно не в любой сети.

Имеет смысл не в любой сети, а только в сети, составленной по определенным принципам, которые хорошо подходят для использования с GLBP. Во-первых, если вы используете коммутаторы, которые на Access-уровне занимаются просто обработкой VLAN-ного трафика, коммутируют кадры, и у вас есть коммутатор Access-овый, Access switch, и есть коммутаторы Distribution, Distribution 1, Distribution 2, естественно, что чаще всего они соединяются вот по такой схеме. Здесь у нас сидит клиент, и здесь у нас Distribution 1, Distribution 2. Если у нас используется коммутация между этими двумя свитчами, если у нас здесь, например, port-channel между Distribution 1 и Distribution 2, как часто бывает, и мы запускаем здесь что-нибудь типа Spanning Tree, то в этом случае вот этот порт, скорее всего, будет заблокирован. Этот коммутатор будет Spanning Tree root-ом, этот будет запасным root-ом, и Spanning Tree нам заблокирует вот этот порт.

В любом случае, если мы запустим GLBP в такой схеме, у нас трафик будет ходить по вот этому линку, и любые пакеты, которые мы будем посылать, в любом случае будут проходить через свитч Distribution 1. Если вдруг мы захотим использовать GLBP, то половину этих пакетов Distribution 1 будет посылать наружу сам, а другую половину будет посылать на Distribution 2, и тот уже будет отправлять эти пакеты наружу. Но получается, что мы вот этот линк загрузили зачем-то зря. Если бы мы сказали: давайте мы сразу посылаем эти пакеты наружу с Distribution 1, было бы лучше, но это надо было бы HSRP запускать. GLBP в такой схеме был бы не нужен. Поэтому если мы хотим использовать GLBP, то мы это должны делать в дизайне, когда у нас так называемый loop-free дизайн, когда вот этого линка между двумя Distribution-ами нету, или, по крайней мере, он есть, но он маршрутизируемый, то есть он не входит в общую коммутацию между Distribution 1 и Distribution 2, и кадры у нас будут бегать либо на Distribution 1, либо на Distribution 2, но они не могут вот так вот уже пройти.

И в такой схеме, да, GLBP можно уже включить. В этой схеме предполагается, что между этими двумя свитчами есть L3-линк, что тут у нас IP-шники какие-то висят, и если вдруг будет нужно передать трафик с Distribution 1 на Distribution 2, это будет происходить уже через маршрутизацию. В такой схеме GLBP использовать можно. Но у такого дизайна есть ряд своих особенностей, и не в любой сети его хорошо использовать. Поэтому GLBP в сети предприятия зачастую использовать не получается. Именно из-за того, что он требует для своей работы очень специфического дизайна. Кроме того, у GLBP есть ряд недостатков чисто финансовых. Он на роутерах цисковских поддерживается практически везде и даже зачастую практически бесплатно. А на свичах, для того чтобы GLBP использовать, вы должны будете купить только самые жирные свичи и купить на них самые жирные лицензии. Если вы хотите на дистрибьюшн свичах его использовать, то эти дистрибьюшн свичи у вас должны быть либо 4500-я линейка,

либо 6500-я, или новые 4500-е и 6800-я. На маленьких свичах, скажем, начального уровня, который Cisco предлагает в линейке Catalyst, GLBP вы не можете включить вообще. А на жирных свичах вы можете его включить, но за деньги. И получается, что в сети предприятия очень специфический протокол, и встретить его довольно редко можно. Да, вы, конечно же, можете сделать здесь роутер на палочке и дальше маршрутизацию проводить через отдельные роутеры, но зачем? Зачем, если это хорошо и удобно делать на дистрибьюшн свичах? Для провайдеров GLBP тоже какой-то странный протокол, потому что провайдеры — это ребята, которые очень любят экономить деньги. Поэтому у них тоже, как правило, маршрутизация вся происходит на свичах, и эти ребята не согласны платить дополнительные деньги за то, чтобы использовать протокол, который гипотетически поможет им более равномерно загружать свои роутеры.

Им проще взять и купить оборудование другого вендора, который не будет заниматься такой лицензионной политикой, чем купить самые жирные железки, купить на них самые жирные лицензии, и после этого получить какую-то фичу. Поэтому у GLBP судьба оказалась довольно грустная. Он в предприятиях оказался не очень интересен, провайдерам оказался не очень интересен, и для него фактически рынка-то особого и нет. Поэтому получается, что да, протокол интересный, да, протокол красивый, да, он позволяет делать очень интересную вещь — одновременно загрузить несколько роутеров, чтобы они думали, что у них одинаковый IP-шник, разные MAC-адреса, и при этом это всё корректно работало. И в случае, если у нас происходит отказ одного роутера, его MAC-адрес перескакивает на другой автоматически. Но в силу, может быть, жадности Cisco, в силу, может быть, специфических особенностей этого протокола, распространения он широкого не получил. Если вам хочется, чтобы у вас несколько роутеров работали одновременно,

и если мы говорим про сеть предприятия, намного проще использовать HSRP и VRRP, разнести трафик по разным VLAN на разные, соответственно, роутеры. У вас в каждой группе HSRP будет один активный роутер, который будет работать. Соответственно, второй роутер в этой группе работать не будет. Но если у нас групп несколько, и мы говорим, что у нас там 10 VLAN-ов есть, мы говорим: в 5 VLAN-ах у нас один активный роутер, в 5 VLAN-ах другой активный роутер. И по факту получается, что в 5 VLAN-ах работает левый роутер, а в других 5 VLAN-ах правый. По факту два роутера есть, оба занимаются делом. И с помощью такого, может быть, немножко ручного механизма мы можем распределить трафик по разным роутерам. Если вдруг один роутер выйдет из строя, значит, второй на себя подхватит всё то, чем занимался первый. GLBP, да, он позволяет это сделать более красиво, более элегантно, но намного более дорого. Поэтому широкого распространения он не получил. Так. Настройка у него почти такая же, как у HSRP,

те же самые команды. Вместо standby пишем GLBP и получаем тот же самый результат. Как в случае с HSRP и VRRP, для GLBP нужно будет настраивать поведение роутера и что будет, если у нас кончится связь со внешним миром. Поэтому на курсе по свитчингу мы, когда будем FHRP проходить, First Hop Redundancy протоколы, обязательно много времени будем уделять настройке отслеживания внешнего мира и что будет, если во внешнем мире что-то происходит: как понизить себе приоритет или как понизить себе вес в протоколе отказоустойчивости шлюза, для того чтобы отказаться добровольно от роли этого самого шлюза, если у нас пропала связь со внешним миром совсем, или понизить себе приоритет, но остаться, возможно, кандидатом на роль шлюза, если у нас какая-то деградированная связь осталась. Такие вещи обязательно должны быть сделаны. В рамках нашего курса и в рамках экзамена про это ничего нету, но обязательно вы должны будете знать, что в корректной настройке

любого протокола отказоустойчивости подобная конфигурация должна присутствовать. На этом тему FHRP я считаю закрытой. И дальше нас ждёт что-то совсем-совсем другое. Спасибо.