Про backup.
Итак, что у нас есть про backup нашей магистрали для мелкого юрика или оператора ?
1) BGP, выливающийся в решение балансировки (скорее по административным причинам - руководство захочет), которое придётся поддерживать руками, чтобы не выбрать лимит трафика (конечно же, есть варианты с одним магистралом и приватными AS). А юрику в регионе оно вообще малореально.
2) Схема с NAT + OER/IP SLA/VRF/скриптами. Смысл схемы в том, что по факту достижимости основного линка (а тут есть куча нюансов, которые сложно обобщить) или качества работы (packet loss, jitter, rtt, etc) принимается решение о выборе default или nat pool+pbr.
Но есть один нюанс - наши сервера (мы хоть и маленькие, но очень гордые - со своими сервами и зоной). А именно - исходящий трафик мы зарезервировали, а что делать с входящим ?
А тут ничего не остаётся делать, кроме как:
Отрицательная сторона - всегда будет входящий трафик по backup-каналу (за счёт DNS) и за него придётся платить.
Тут начальство делает умное лицо и говорит: "Eсли мы за него уже платим, так давайте использовать его по полной !"
И тут начинается песня про п.1 - и главное - вовремя донести мысль, что за такие желания надо будет платить:
1) AS + PI/LIR + каналы + единоразовую настройку + за железо, которое примет full view (не существенно для юрлица, но существенно для провайдера - может просто не найтись человека, который сможет решать проблемы с ассиметрией).
2) AS + PI/LIR + каналы + единоразовую настройку + железо, которое вытянет ваш трафик с PBR (опять же, проблемы для провайдера с разрывом клиентских сессий)
Словом, решить технически (в идеале техника должна обеспечивать бизнес) это можно, но зачастую будет стоить дороже.
1) BGP, выливающийся в решение балансировки (скорее по административным причинам - руководство захочет), которое придётся поддерживать руками, чтобы не выбрать лимит трафика (конечно же, есть варианты с одним магистралом и приватными AS). А юрику в регионе оно вообще малореально.
2) Схема с NAT + OER/IP SLA/VRF/скриптами. Смысл схемы в том, что по факту достижимости основного линка (а тут есть куча нюансов, которые сложно обобщить) или качества работы (packet loss, jitter, rtt, etc) принимается решение о выборе default или nat pool+pbr.
Но есть один нюанс - наши сервера (мы хоть и маленькие, но очень гордые - со своими сервами и зоной). А именно - исходящий трафик мы зарезервировали, а что делать с входящим ?
А тут ничего не остаётся делать, кроме как:
- Прописать для нашей зоны запись NS с IP из каждого выделенного блока адресов вышестоящего провайдера и ловить эти запросы во view с match-destinations.
- Выставить маленький TTL
- Выдавать те адреса, которые на текущий момент основные.
Отрицательная сторона - всегда будет входящий трафик по backup-каналу (за счёт DNS) и за него придётся платить.
Тут начальство делает умное лицо и говорит: "Eсли мы за него уже платим, так давайте использовать его по полной !"
И тут начинается песня про п.1 - и главное - вовремя донести мысль, что за такие желания надо будет платить:
1) AS + PI/LIR + каналы + единоразовую настройку + за железо, которое примет full view (не существенно для юрлица, но существенно для провайдера - может просто не найтись человека, который сможет решать проблемы с ассиметрией).
2) AS + PI/LIR + каналы + единоразовую настройку + железо, которое вытянет ваш трафик с PBR (опять же, проблемы для провайдера с разрывом клиентских сессий)
Словом, решить технически (в идеале техника должна обеспечивать бизнес) это можно, но зачастую будет стоить дороже.