Перейти к содержимому
Калькуляторы

HSRP + bridge-domain

Доброго времени суток.

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

Есть сеть достаточно большого предприятия. На центральном узле установлены два Cisco ASR1001-X (ASR1 и ASR2). Каждый из удаленных офисов подключен напрямую оптикой к каждому ASR для обеспечения безотказной работы в случае падения одного из ASR или линков. Для этого на ASR'ах настроен протокол HSRP.

При этом по мере увеличения сети, появилась необходимость узлам, разнесенным по разным офисам, предоставлять доступ из подсети 10.1.0.0/17 центрального узла. Для этого был создан VLAN 24, который существует в каждом сегменте и объединяется на ASR при помощи технологии bridge-domain. Кроме того, VLAN 24 распространяет подсеть 10.1.136.0/24 (висит как secondary на VLAN40). Так же существует VLAN 16 для распространения подсети белых айпишников, поскольку часть серверов исторически получала напрямую белые адреса на интерфейсы.

Основная проблема использования bridge-domain для передачи вланов между сегментами является отсутствие отказоустойчивости. Кроме того, из-за использования HSRP нельзя настраивать bridge-domain одновременно на обоих ASR, поскольку возможно появление L2 петли. На данный момент при выходе из строя ASR1 все L3 интерфейсы перейдут на ASR2 незаметно для пользователей. А вот бридж необходимо переносить руками.

Собственно, вопрос заключается в том, как реализовать нормальную работу HSRP и бридж-домена на ASR без петель и автоматическим переносом всех сервисов в случае падения любого из ASR?

На ASR1 на интерфейсах такой конфиг: 

interface TenGigabitEthernet0/1/3
 description OFFICE2_CiscoAGG
 no ip address
 cdp enable
 service instance 16 ethernet
  encapsulation dot1q 16
  rewrite ingress tag pop 1 symmetric
  bridge-domain 16
 !
 service instance 12 ethernet
  encapsulation dot1q 24
  rewrite ingress tag pop 1 symmetric
  bridge-domain 24
 !
interface TenGigabitEthernet0/1/3.40
 description LAN_OFFICE2
 encapsulation dot1Q 40
 ip address 10.1.136.3 255.255.255.0 secondary
 ip address 10.1.0.3 255.255.128.0
 ip nat inside
 standby version 2
 standby 20 ip 10.1.0.1
 standby 20 ip 10.1.136.1 secondary
 standby 20 timers 1 3
 standby 20 priority 110
 standby 20 preempt
 standby 20 track TenGigabitEthernet0/1/1 15
 standby 20 track TenGigabitEthernet0/1/2 15
 standby 20 track TenGigabitEthernet0/1/3 15
 ntp broadcast
 cdp enable

 

482733032_.thumb.PNG.3bde8658347d7a5e6c2f8274f570bb1e.PNG

Изменено пользователем thelastmanonmoon
Внес изменения в схему

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если опасаетесь L2-петли, то и решать проблему надо на этом же уровне.

Первое что приходит в голову - это вариации на тему stp, в случае с циской rapid pvst.

Ройте документацию, умеет ли ASR rapid pvst на bridge-domain, или хотя бы прозрачно пропускать служебные пакеты stp от соседних коммутаторов через bridge-domain.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Посмотрите в сторону MST Access gateway или Mutichassis LACP (MC-LAG). А вы принципиально построили плоскую сеть? С L3 было бы гораздо проще.

 

IOS-XR spanning tree.pdf

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@fox_m к сожалению, я не строил эту сеть. Досталась в наследство. Пытаюсь добиться стабильной работы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если не хочете 1го пакета не потерять, то TCP. L3+tunel.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

MST AG выглядит интересно. Вопрос только в том, будет ли он работать в паре с HSRP.? При создании групп на любом L3 интерфейсе присваивается виртуальный mac адрес, который будет одинаковым на обоих ASR. Хотя, кажется, должен работать такой вариант.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я бы медленно менял дизайн сети... А не устранял грабли дизайна путем изменения технологии...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

On 5/23/2019 at 3:23 PM, thelastmanonmoon said:

в случае падения одного из ASR

При таком "дизайне" сети это _самое_ маловероятное из проблем, которые возможны.

"Переезжайте" филиалы в отдельные IP сети, отгораживайте их за отдельные L3 интерфейсы (SVI или сабинтерфейсы). Да это больно и нужно поработать, зато это полезно.

 

В филиалах, я так понимаю, роутеров нет впринципе?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

7 минут назад, ShyLion сказал:

Переезжайте" филиалы в отдельные IP сети, отгораживайте их за отдельные L3 интерфейсы

Именно этого я и хочу добиться в перспективе. 

8 минут назад, ShyLion сказал:

 В филиалах, я так понимаю, роутеров нет впринципе?

Да, в филиалах роутеров нет. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.