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