[ThreeDHead]

Стоит задача резервирования двух устройств CGN, путём поднятия на них VRRP.

Сторона "А", Subscribers Side, OSPF нет, VRRP уже поднят.

Сторона "Б", Network Side, надо поднять OSPF и что-то сделать с VRRP.

 

На стороне "А" всё просто, оно уже работает.

Вот непонятно что делать со стороной "Б". В принципе, мне там единый IP не нужен. Сейчас BD-8810 принимает по OSPF от CGN1 IP-адреса (реальники). Если я на BD-8810 сконфигурирую OSPF в сторону CGN2 (VLAN20), то и CGN1 и CGN2 отгрузят свои таблицы в BD-8810, начнется хаос.

Если поднять единый IP по VRRP, на стороне "Б", то OSPF будет отгружаться с активного CGN?

[NikAlexAn]

А на CGN2 метрику на redistibute поднять нельзя?

 

Если не ошибаюсь то протоколы маршрутизации не работают с виртуального VRRP адреса.

Изменено 18 августа, 2016 пользователем NikAlexAn

[zi_rus]

что-то сделать с VRRP.

 

а что с ним сейчас?

[ThreeDHead]

А на CGN2 метрику на redistibute поднять нельзя?

А что это даст? Он и так выгружает только свои внешние "коннектед" IP-адреса.

И CGN1,и CGN2 выгрузят маршруты к одним и тем-же реальникам, хотя активным будет, например, CGN1. Этого надо избежать.

 

Если не ошибаюсь то протоколы маршрутизации не работают с виртуального VRRP адреса.

У меня нет сомнений на этот счет, т.к. это "виртуальный" IP прописывается на интерфейсе со всеми вытикающими, присутствием в ARP и т.д.

Именно плавающий IP я хочу описать на BD-8810, как соседа.

 

Я ночью сегодня испытаю эту схему, план работ уже готов. А завтра утром выложу блок-схему с конфигами.

 

а что с ним сейчас?

Имелось ввиду, что поднимать его на стороне "Б" или нет.

- Если не поднимать, то как отгружать IP-адреса по OSPF только с активного CGN?

- Если поднимать, то заведётся-ли по верх него OSPF?

[zi_rus]

- Если не поднимать, то как отгружать IP-адреса по OSPF только с активного CGN?

А что это даст? Он и так выгружает только свои внешние "коннектед" IP-адреса.

И CGN1,и CGN2 выгрузят маршруты к одним и тем-же реальникам, хотя активным будет, например, CGN1. Этого надо избежать.

собсно это и надо делать

ospf metric type 2

и дальше на одном cgn анонсить маршруты с метрикой 100, а со второго - 200. пока первый живой, все роутеры в сети будут слать трафик в его сторону (главное чтобы cgn не были замкнуты по оспф друг с другом), умрет - и в сети останутся роуты только со второго cgn

[ThreeDHead]

1. OSPF поверх плавающего IP VRRP работать будет. Для того чтобы это получилось, нужен тип OSPF - point-to-multipoint. У меня так не получилось, потому что BD-8810 не умеет point-to-multipoint;

2. VRRP на стороне "Б" мне всё-таки оказался нужным, потому что Static NAT не редистрибутися с CGN, приходится их статикой направлять c BD-8810 на плавающий IP стороны "Б". Это хорошо;

3. Выкрутился с помощью метрик, CGN1 - 100, CGN2 - 200, спасибо zi_rus;

4. По большому счету, от OSPF я мог и отказаться вовсе, т.к. у меня не так много сетей реальников, можно было и статикой прописать, на плавающий IP стороны "Б" (п.2).

 

Блок-схему прикреплю попозже.

[ThreeDHead]

Блок-схема

[ThreeDHead]

Конфигурация VRRP-A на CGN-ах:

 

CGN1:

!
vrrp-a common 
 device-id 1 
 set-id 1 
 enable 
!
vrrp-a vrid 0 
 floating-ip 10.0.1.100 
 floating-ip 10.0.1.108 
!
vrrp-a interface ethernet 9
 vlan 19 
!
vrrp-a preferred-session-sync-port ethernet 9 vlan 19 

CGN2:

vrrp-a common 
 device-id 2 
 set-id 1 
 enable 
!
vrrp-a vrid 0 
 floating-ip 10.0.1.100 
 floating-ip 10.0.1.108 
!
vrrp-a interface ethernet 5 
 vlan 19 
!
vrrp-a preferred-session-sync-port ethernet 5 vlan 19 

По 19-му VLAN-у они будут синькаться и HearBeat чекать, этот VLAN на стороне "А", до HP-6600.

[ThreeDHead]

Собственно, с метриками вроде красиво, но тоже не торт. Если я захочу руками сделать слейв->мастером один из CGN, то как раз метрики окажут медвежию услугу. Скорее всего опишу эти реальники статикой на плаваающий IP (п.4)

 

Ну или можно тушить порт на стороне "А" на мастере, чтобы они поменялись местами, тогда метрики отработают как надо.

[zi_rus]

4. По большому счету, от OSPF я мог и отказаться вовсе, т.к. у меня не так много сетей реальников, можно было и статикой прописать, на плавающий IP стороны "Б" (п.2).

 

я бы от vrrp отказывался при возможности. вррп это костыль для статической маршрутизации, когда работаешь с сетевыми железками все же лучше использовать динамические протоколы. попробуйте сравните чего будет стоить настроить балансировку между двумя железками - с ospf это будет на порядок проще

[zi_rus]

Собственно, с метриками вроде красиво, но тоже не торт. Если я захочу руками сделать слейв->мастером один из CGN, то как раз метрики окажут медвежию услугу. Скорее всего опишу эти реальники статикой на плаваающий IP (п.4)

 

Ну или можно тушить порт на стороне "А" на мастере, чтобы они поменялись местами, тогда метрики отработают как надо.

http://packetlife.net/blog/2008/oct/29/ospf-stub-router-advertisement/

не?