Лучшая практика для комбинации HSRP и ECMP

19

Комбинация ECMP (или других причин асимметричных путей) и HSRP по умолчанию нарушена в Cisco IOS; Поведение по умолчанию с этим дизайном чрезмерно затопляет одноадресный трафик.

Какова наилучшая практика использования HSRP с ECMP для предотвращения неизвестных наводнений одноадресной рассылки?

Детали / Фон

У нас есть топология HSRP, аналогичная первой диаграмме ниже для многих наших объектов. Наши маршрутизаторы Cisco WAN имеют равные по стоимости маршруты ко всем остальным сайтам; таким образом, мы можем постоянно видеть асимметричные эффекты маршрутизации. Обычно мы назначаем R1 первичным HSRP, но ECMP разрешает возврат трафика через R1 или R2.

Проблема заключается в том, что, когда ПК1 монтирует удаленный диск iSCSI через WAN, трафик покидает сайт через R1, но может возвращаться через R2. Пока трафик iSCSI возвращается через R1, проблем нет.

HSRP_Broken_00

Проблема возникает, когда трафик PC1 возвращается через R2. Предположим, что сеанс iSCSI начинается в 8:00:00, и оба маршрутизатора и оба коммутатора одновременно изучают Mac PC1. Между 8:00:00 и 8:00:05 проблем с переполнением нет, поскольку оба коммутатора все еще имеют mac-адрес PC1 в своей таблице CAM.

HSRP_Broken_01

Через пять минут после начала сеанса iSCSI запись CAM в S2 для Mac PC1 истекает из таблицы CAM, и S2 перенаправляет трафик PC1 через все порты (в данном случае в Po1, Gi0 / 3 и Gi0 / 4). Если сеанс iSCSI ПК1 потребляет большую полосу пропускания, это неизвестное одноадресное наводнение может высвободить нетривиальную емкость из каналов связи с ПК3 и ПК4.

Коммутаторы Cisco IOS имеют таймер CAM по умолчанию 300 секунд ...

S2# show mac address-table aging-time
Vlan Aging Time
---- ----------
1    300
17   300

Однако таймер ARP интерфейса Cisco IOS по умолчанию составляет 4 часа ...

R2# show interface gi0/0
GigabitEthernet0/0 is up, line protocol is up 
  Hardware is AmdP2, address is 000a.dead.beef (bia 000a.dead.beef)
  Internet address is 172.17.1.252/24
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  ARP type: ARPA, ARP Timeout 04:00:00       <--------------

Поэтому S2 начинает заполнять трафик iSCSI PC1 через пять минут.

HSRP_Broken_02

Майк Пеннингтон
источник
Почему люди продолжают публиковать вопросы, а затем сами отвечают на них? Нет, как в, искали и нашли ответ, они уже были? Это сайт вопросов и ответов, а не блог (не то, чтобы вы не написали хорошую
статью
8
@javano: автоответчик явно поощряется SE. ref meta.networkengineering.stackexchange.com/questions/4/…
Крейг Константин
1
@CraigConstantine Да, я знаю, но я уверен, что люди публикуют вопросы, а затем отвечают через некоторое время, а не через некоторое время, когда они выясняют ответ на вопрос (даже если это только 5 минут спустя), они отвечают сразу потому что они уже знали ответ до публикации вопроса. Я нахожу это немного странным.
jwbensley
6
Тем не менее факт остается фактом, что написание Q и немедленного ответа явно приветствуется.
Крейг Константин
4
@javano, если вы решите проблему, с которой, по вашему мнению, столкнутся другие люди, SE хочет, чтобы трафик поисковой системы разрешил эту проблему ... им все равно, отправляю ли я ответ одновременно или нет ... на самом деле, в нижней части веб-формы вопроса есть небольшой флажок «Ответь на свой вопрос - поделись своими знаниями в стиле вопросов и ответов»
Майк Пеннингтон,

Ответы:

14

Простой ответ - сделать таймер CAM равным или немного длиннее, чем таймер ARP соответствующего интерфейса , но есть по крайней мере три различных варианта на выбор ...

Вариант 1: опустить все интерфейсные таймеры ARP

Этот вариант работает лучше всего, если у вас есть коммутируемая сеть уровня 2 приличного размера, разумное количество записей ARP и несколько маршрутизируемых интерфейсов. Этот метод также предпочтителен, если вы хотите, чтобы записи Mac на ПК быстро выходили из топологии.

  • На всех интерфейсах Ethernet IOS, обращенных к коммутатору Ethernet: arp timeout 240
  • На всех интерфейсах IOS Ethernet, обращенных к коммутатору Ethernet: hold-queue 200 inи hold-queue 200 outво избежание сброса пакетов ARP во время периодических обновлений ARP (эти ограничения могут быть выше или ниже в зависимости от того, сколько обновлений ARP вы считаете нужным обрабатывать одновременно). Если вы настраиваете значения выборочного отбрасывания пакетов , вам следует следовать указаниям, приведенным в документе, который я связал.

Это вынуждает Cisco IOS обновить таблицу ARP в течение четырех минут, если это не произошло иначе для данной записи ARP. Очевидным недостатком является то, что это плохо масштабируется, если у вас много записей ARP ... ограничения зависят от платформы. Я использовал это с несколькими сотнями ARP на маршрутизатор на Catalyst 4500/6500 (SVI Layer3) без каких-либо проблем.

Вариант 2: увеличить переключатель таймеров CAM

Эта опция работает лучше всего, если у вас есть большое количество записей ARP (т. Е. Тысячи, например, в интенсивной среде VMWare).

  • На всех коммутаторах IOS: mac address-table aging-time 14400или mac address-table aging-time 14400 vlan <vlan-id>для любого Vlan, который имеет значение.

Это изменение корректирует таймеры, которые, как полагают большинство людей, установлены на 300 секунд (в Cisco IOS), поэтому обязательно включите их в документацию по непрерывности. Побочным эффектом этого является то, что записи в таблице CAM задерживаются на 4 часа после удаления ПК (что может быть как хорошим, так и плохим, в зависимости от вашего PoV). Если 4 часа слишком долго, посмотрите следующий вариант ...

Вариант 3: Измените и интерфейсные таймеры ARP, и таймеры CAM коммутатора

Этот параметр позволяет избежать ужасно длинных таймеров CAM в варианте 2 за счет большей конфигурации. Вы можете выбрать, нужно ли вам 900 секунд, 1800 секунд или что-то еще ... просто убедитесь, что ваши таймеры CAM и ARP совпадают; таким образом, вам нужно будет настроить вариант 1 и вариант 2 в вашей топологии.

Майк Пеннингтон
источник
4
Мы решили эту проблему, выбрав первое предложенное решение, но мы не были уверены в порядке, в котором IOS будет очищать таблицу, а затем мы установили тайм-аут ARP на 293 с (ближайшее простое число ниже тайм-аута таблицы mac-address). Все еще не знаю, был ли это хороший выбор или нет
Марко Марзетти
1
Технически Cisco IOS запускает программу ARP Walker с интервалом в 60 секунд, поэтому вы должны использовать 240 ... Я не учел это в своем ответе ... редактировать его в ... Мне любопытно, почему вы выбрали простое число ...
Майк Пеннингтон
ACK. Время ожидания ARP, меньшее или равное времени ожидания MAC, должно быть BCP. HSRP даже не нужен, просто, если есть два маршрутизатора, он может кусать вас и вызывать даже петли.
ytti
Не знал Так что наш трюк совершенно бесполезен. Мы выбрали простое число, чтобы минимизировать перекрытие таймеров.
Марко Марзетти
4
@MikePennington, спасибо. В любом случае, вы правы Разрешение тайм-аута ARP выполняется за считанные минуты
Марко Марзетти
1

Для меня ECMP - это реальная проблема, поэтому в дополнение к вышеупомянутым шагам по ограничению неизвестного одноадресного потока вы также можете настроить параметры маршрута в направлении WAN, чтобы R1 был предпочтительнее R2 для обратного трафика. Одним из способов достижения этого является использование списка рассылки на R2 следующим образом: (EIGRP используется только для примера, того же можно достичь с помощью OSPF или BGP с другими командами)

!
ip prefix-list R1-PREFER seq 5, разрешение 172.17.1.0/24
!
карта маршрутов R1-PREFER-MAP разрешение 10
 сопоставить префикс-список IP-адресов R1-PREFER
 установить метрику 1 1 1 1 1
... (разрешить все другие маршруты)
!
маршрутизатор EIGRP 1
 ....
 карта маршрутов распространения списка R1-PREFER-MAP из Ser1 / 0
 ....
!

Это приведет к тому, что WAN перенаправит весь трафик для 172.17.1.0 на R1. В случае сбоя R1 Se1 / 0 маршрут будет установлен в направлении R2. Вы можете дополнительно настроить эти показатели, чтобы резервный маршрут к R2 фактически стал возможным преемником для более быстрого переключения при сбое. HSRP и отслеживание позаботятся о выходе трафика.

smoothbSE
источник
по сути, вы отвечаете на вопрос, который вы хотите, а не на мой вопрос ... который требует как fhrp, так и ecmp
Майк Пеннингтон
извините за это - я привыкла к этому форуму и пропустила это требование!
smoothbSE
Нет проблем ... добро пожаловать в NE :)
Майк Пеннингтон
0

Идея, если не использовать ECMP, если HSRP используется, может подойти для СЕРВЕРОВ, где входной трафик может быть выше, чем выходной трафик, в ситуации ПК В ОБЩЕМ входном трафике от WAN (ответы) выше, чем выходной трафик (входной). Нам нравится, что большинство людей просто устанавливают таймеры ARP. вы можете связываться с таймерами CAM, НО, если у вас есть, скажем, MDF с коммутатором уровня 3 и IDF с 2 коммутаторами сбора и, скажем, 5 коммутаторами доступа, настроить LOT SVI проще, чем делать все коммутаторы доступа.

fredpbaker
источник
0

Можно использовать стек коммутаторов для смягчения этой проблемы истечения срока ввода MAC-адреса во втором коммутаторе.

Евгений Смирнов
источник
0

Ах, я помню это. Несколько недель назад я имел дело с этой работой. Один недостаток заключается в том, что события STP переведут виртуальные сети в режим быстрого старения, поэтому установка таймера MAC дольше таймера ARP не помогает

Я решил эту проблему, принудительно вернув ECMP с серверов, создав два плавающих шлюза HSRP, с одним основным на каждом маршрутизаторе. Затем мы настроили оба шлюза на каждом хосте. Подобным образом передавая хост-трафик к R1 и R2, мы были бы уверены, что R2 никогда не устареет MAC-адресов.

В идеале это не было бы проблемой, если бы L2 / 3 переключал очищенные записи ARP, связанные с устаревшими MAC-адресами. Затем следующий пакет к IP приведет к новому запросу ARP, заполнив кеш ARP и таблицу MAC. Я думаю, что Cisco в конечном счете реализовал это, но я не могу сказать точно.

каркать
источник
0

Резюме: MC-LAG или HSRP GARP

Я никогда не был фанатом настройки таймеров. Таймеры устанавливаются определенным образом обычно по многим причинам. Изменяя их:

  • потенциально интенсивно в эксплуатации, чтобы поддерживать везде одинаково
  • делает вещи более сложными и трудными для устранения неполадок
  • как показал недавний комментатор, может иметь неожиданные побочные эффекты
  • может не «хорошо играть» с будущими улучшениями Cisco

С другой стороны:

  1. Используйте MC-LAG (он же «MEC» в документации Cisco). Это ваш лучший вариант, хотя вы должны понимать сценарии развертывания, в которых можно использовать MC-LAG (это не универсальное решение, и его следует развертывать только после соответствующего исследования и тестирования). Варианты MC-LAG зависят от аппаратного обеспечения. Примеры:

    а. Укладка (Cat 3k)

    б. VSS (Cat4k / 6k)

    с. VPC (Nexus)

    д. Псевдо млACP (ASR1k)

    е. MC-LAG (ASR9k)

    е. Кластеризация (ASA)

  2. Включите HSRP для периодической отправки бесплатных пакетов ARP . Конечно, это похоже на изменение таймеров, но это гораздо более изящное изменение, чем манипулирование таблицами CAM и таймерами ARP. (Обратите внимание, что это зависит от вашей аппаратной и программной комбинации, не все реализации HSRP предлагают это.)

    По умолчанию HSRP отправляет 3 GARP через 0, 2 и 4 секунды после того, как маршрутизатор становится шлюзом пересылки. Тем не менее, есть параметр конфигурации, который позволяет вам выбрать количество GARP (включая «бесконечный») и интервал.

Я довольно широко использую MC-LAG, особенно VSS, VPC и Clustering (я не фанат стека).

Там, где я не могу использовать MC-LAG или GLBP, это то, что я применяю к моим граничным маршрутизаторам L2 / L3 в кампусе (у меня кампус из 350 зданий, поэтому я довольно интенсивно использую Cat6k):

Cat6k-v15(config)#interface vlan 100
Cat6k-v15(config-if)#standby arp ?
  gratuitous  Setup gratuitous ARP interval and count

Cat6k-v15(config-if)#standby arp gratuitous ?
  count     Set HSRP gratuitous ARP count
  interval  Set HSRP gratuitous ARP interval
  <cr>

Cat6k-v15(config-if)#standby arp gratuitous count ?
  <0-60>  Number of gratuitous ARPs to send after group is activated (0 for continuous)

Cat6k-v15(config-if)#standby arp gratuitous count 0 ?
  count     Set HSRP gratuitous ARP count
  interval  Set HSRP gratuitous ARP interval
  <cr>

Cat6k-v15(config-if)#standby arp gratuitous count 0 interval ?
  <3-1800>  Gratuitous ARP Interval (sec)

Cat6k-v15(config-if)#standby arp gratuitous count 0 interval 60 ?
  count     Set HSRP gratuitous ARP count
  interval  Set HSRP gratuitous ARP interval
  <cr>

Cat6k-v15(config-if)#standby arp gratuitous count 0 interval 60 

(Я бы опубликовал ссылки на все это, но у меня недостаточно высокой «репутации» на этом сайте, чтобы публиковать более двух URL.)

Вейлин Пигорш
источник
То, что вы называете MC-LAG, безусловно, является вариантом, но его доступность на классических платформах IOS невелика. Мне также не хватает того, как HSRP Gratuitous ARP помогает решить эту проблему. Используя пример из моего вопроса, не могли бы вы рассказать о том, как HSRP Gratuitous ARP решает тайм-аут входа ARP 172.17.1.1? Обратите внимание, что по умолчанию GW 172.17.1.254
Майк Пеннингтон
Длинный ответ, поэтому позвольте мне разбить это на две части. Часть 1 ... Проблема с HSRP заключается в том, что маршрутизатор отвечает на запрос ARP с помощью виртуального MAC. Однако когда маршрутизатор пересылает дейтаграмму хосту, он использует физический MAC-адрес. Коммутаторы очищают свою таблицу пересылки довольно быстро (часто 300 секунд или 5 минут), но записи ARP часто задерживаются гораздо дольше (обычно 8 часов).
Weylin Piegorsch
Часть 2 ... По истечении времени ожидания виртуального MAC-адреса из таблицы переадресации трафик с сервера на виртуальный MAC становится «неизвестным одноадресным», когда по умолчанию коммутатор работает в режиме концентратора и затопляет весь трафик. порты. Периодически отправляя GARP, маршрутизатор обновляет таблицу переадресации коммутатора. Кроме того, при отправке GARP таблица ARP на сервере обновляется, что устраняет необходимость отправки запроса ARP.
Вейлин Пигорш
Вторично к моему ответу из двух частей, я только что понял, что вопрос задается в противоположном направлении: MAC-адрес сервера сбрасывается с коммутаторов, а не виртуальный MAC-адрес маршрутизатора. У нас была эта конкретная проблема, и в итоге мы решили ее изначально с помощью MC-LAG (в частности, VPC), а позже, так как мы уже использовали Nexus, мы переключились на FabricPath или TRILL, что позволило устранить проблему. Но оба они зависят от оборудования и топологии.
Вейлин Пигорш
Я только что понял, что мой оригинальный комментарий действителен, но, к сожалению, неполон. Не только MC-LAG, но и MC-LAG на обоих уровнях. Затем вы имеете дело с общей таблицей CAM как на уровне коммутатора, так и на уровне маршрутизатора.
Вейлин Пигорш
0

Я только что понял, что мой оригинальный комментарий действителен, но, к сожалению, неполон. Рекомендация разработчиков, не зависящая от производителя, состоит в том, чтобы строить треугольники, а не прямоугольники. Так:

  1. Не только MC-LAG, но и MC-LAG на обоих уровнях. Затем вы имеете дело с общей таблицей CAM как на уровне коммутатора, так и на уровне маршрутизатора.

  2. Если вы не можете сделать это, MC-LAG или маршрутизатор или коммутатор, и MC-LAG на другой уровень с дополнительной связью (то есть полная сетка между маршрутизаторами и коммутаторами). STP обеспечит топологию без петель.

  3. Если вы не можете этого сделать, по-прежнему используйте сетевые маршрутизаторы и коммутаторы. STP обеспечит топологию без петель, а таблицы CAM коммутатора будут по-прежнему знать все соответствующие правила пересылки MAC. Сервер всегда отправляет свой MAC, и если вы сконфигурируете GSRP HSRP с интервалом в 1 минуту, коммутаторы также не забудут vMAC HSRP.

Предпочтительные варианты в этом порядке. Но, по крайней мере, установите эту дополнительную пару ссылок.

Вейлин Пигорш
источник