thelastmanonmoon Опубликовано 23 мая, 2019 (изменено) · Жалоба Доброго времени суток. Прошу оказать помощь в решении следующей проблемы. Есть сеть достаточно большого предприятия. На центральном узле установлены два 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 Изменено 23 мая, 2019 пользователем thelastmanonmoon Внес изменения в схему Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
azhur Опубликовано 23 мая, 2019 · Жалоба Если опасаетесь L2-петли, то и решать проблему надо на этом же уровне. Первое что приходит в голову - это вариации на тему stp, в случае с циской rapid pvst. Ройте документацию, умеет ли ASR rapid pvst на bridge-domain, или хотя бы прозрачно пропускать служебные пакеты stp от соседних коммутаторов через bridge-domain. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fox_m Опубликовано 23 мая, 2019 · Жалоба Посмотрите в сторону MST Access gateway или Mutichassis LACP (MC-LAG). А вы принципиально построили плоскую сеть? С L3 было бы гораздо проще. IOS-XR spanning tree.pdf Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
thelastmanonmoon Опубликовано 23 мая, 2019 · Жалоба @fox_m к сожалению, я не строил эту сеть. Досталась в наследство. Пытаюсь добиться стабильной работы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
h3ll1 Опубликовано 23 мая, 2019 · Жалоба Если не хочете 1го пакета не потерять, то TCP. L3+tunel. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
thelastmanonmoon Опубликовано 24 мая, 2019 · Жалоба MST AG выглядит интересно. Вопрос только в том, будет ли он работать в паре с HSRP.? При создании групп на любом L3 интерфейсе присваивается виртуальный mac адрес, который будет одинаковым на обоих ASR. Хотя, кажется, должен работать такой вариант. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zoro Опубликовано 25 мая, 2019 · Жалоба Я бы медленно менял дизайн сети... А не устранял грабли дизайна путем изменения технологии... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ShyLion Опубликовано 27 мая, 2019 · Жалоба On 5/23/2019 at 3:23 PM, thelastmanonmoon said: в случае падения одного из ASR При таком "дизайне" сети это _самое_ маловероятное из проблем, которые возможны. "Переезжайте" филиалы в отдельные IP сети, отгораживайте их за отдельные L3 интерфейсы (SVI или сабинтерфейсы). Да это больно и нужно поработать, зато это полезно. В филиалах, я так понимаю, роутеров нет впринципе? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
thelastmanonmoon Опубликовано 27 мая, 2019 · Жалоба 7 минут назад, ShyLion сказал: Переезжайте" филиалы в отдельные IP сети, отгораживайте их за отдельные L3 интерфейсы Именно этого я и хочу добиться в перспективе. 8 минут назад, ShyLion сказал: В филиалах, я так понимаю, роутеров нет впринципе? Да, в филиалах роутеров нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...