Jump to content
Калькуляторы

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

Edited by thelastmanonmoon
Внес изменения в схему

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

 

IOS-XR spanning tree.pdf

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
On 5/23/2019 at 3:23 PM, thelastmanonmoon said:

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

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

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

 

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

Share this post


Link to post
Share on other sites
7 минут назад, ShyLion сказал:

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

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

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

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now