Восстановление
Материалы по PBT обещают восстановление за магические 50 миллисекунд. Как это у них реализуется?
Материалы по PBT обещают восстановление за магические 50 миллисекунд. Как это у них реализуется?
Во-первых, у них есть только path protection. Это означает, что для
каждого защищенного пути создается запасной, и при сбое head end
туннеля переключает трафик на запасной путь.
Хорошо это или плохо? На мой взгляд, это очевидно хуже, чем локальное восстановление.
Path protection означает распухание forwarding state. В случае path protection количество путей удваивается. А в случае локального восстановления в стиле facility backup количество дополнительных тоннелей пропорционально количеству защищаемых линков между узлами.
Может ли PBT реализовать локальную защиту а-ля MPLS FRR? Нет.
Реализация защиты в стиле one-to-one (в терминологии RFC4090 - detours) основана на том, что MPLS метка меняется на каждом хопе, а в PBT пара (B-VID, B-DA) всегда остается неизменной.
Реализация защиты в стиле facility backup (в терминологии RFC4090 - bypasses) требует возможности на промежуточном узле, являющемся PLR (Point of Local Recovery) добавить дополнительную метку. В архитектуре PBT такая возможность не предусматривается.
Есть ли еще какие-то приемущества у MPLS в плане восстановления? Да. Гибкость. В PBT мы можем либо защить туннель, либо не защитить туннель.
Мы можем использовать разные способы развертывания защиты в MPLS сети:
* Например, one-hop туннели, которые я как-то упоминал в одном из своих постов.
*Во-вторых, мы можем (вернее, сможем в недалеком будущем, если наконец некоторые вендоры прекратят спать за штурвалом) использовать иерархические туннели, которые сильно помогут масштабируемости RSVP-TE.
* И в-третьих, совсем скоро мы сможем делать защиту вообще без RSVP-TE - это называется IPFRR. IPFRR пока только в разработке, но работы продвигаются с хорошей скоростью. а там, глядишь, и вендоры подтянутся со своими реализациями. Следите за драфтами и пинайте вендоров :)
А как в PBT обнаруживаются сбои? Раз между узлами нет никакой сигнализации, то единственный способ обнаруживать непроходимость трафика - это запустить какой-нибудь постоянный мониторинг end-to-end. PBT для этого использует Connectivity Fault Management (802.1ag_. Логично? Логично. Если есть механизм, то почему бы его не использовать?
Что это означает на практике? На практике это означает, что для каждого PBT-туннеля есть возвратный, который идет точно по тому же пути и несет возвратные CFM-фреймы. Как я понял из описания, этот туннель не рабочий, и полезный трафик по нему не идет. Что из этого следует? Правильно. Из этого следует, что мы еще раз удвоили forwarding state.
Что это означает еще? Это означает серьезную нагрузку на CPU как head end'а, так и tail end'а. Чтобы получить переключение в пределах 50мс, мы должны проверять прохождение трафика примерно каждые 10мс. Причем мониторить надо как первичный, так и защитного путь. В защищенной full mesh сети из, скажем, 1000 узлов, head end должен генерировать, а tail end принимать 200000 пакетов в секунду. Что совсем не мало.
Интересно, доберусь я сегодня до сервисов?
This entry was originally posted in my livejournal
Хорошо это или плохо? На мой взгляд, это очевидно хуже, чем локальное восстановление.
Path protection означает распухание forwarding state. В случае path protection количество путей удваивается. А в случае локального восстановления в стиле facility backup количество дополнительных тоннелей пропорционально количеству защищаемых линков между узлами.
Может ли PBT реализовать локальную защиту а-ля MPLS FRR? Нет.
Реализация защиты в стиле one-to-one (в терминологии RFC4090 - detours) основана на том, что MPLS метка меняется на каждом хопе, а в PBT пара (B-VID, B-DA) всегда остается неизменной.
Реализация защиты в стиле facility backup (в терминологии RFC4090 - bypasses) требует возможности на промежуточном узле, являющемся PLR (Point of Local Recovery) добавить дополнительную метку. В архитектуре PBT такая возможность не предусматривается.
Есть ли еще какие-то приемущества у MPLS в плане восстановления? Да. Гибкость. В PBT мы можем либо защить туннель, либо не защитить туннель.
Мы можем использовать разные способы развертывания защиты в MPLS сети:
* Например, one-hop туннели, которые я как-то упоминал в одном из своих постов.
*Во-вторых, мы можем (вернее, сможем в недалеком будущем, если наконец некоторые вендоры прекратят спать за штурвалом) использовать иерархические туннели, которые сильно помогут масштабируемости RSVP-TE.
* И в-третьих, совсем скоро мы сможем делать защиту вообще без RSVP-TE - это называется IPFRR. IPFRR пока только в разработке, но работы продвигаются с хорошей скоростью. а там, глядишь, и вендоры подтянутся со своими реализациями. Следите за драфтами и пинайте вендоров :)
А как в PBT обнаруживаются сбои? Раз между узлами нет никакой сигнализации, то единственный способ обнаруживать непроходимость трафика - это запустить какой-нибудь постоянный мониторинг end-to-end. PBT для этого использует Connectivity Fault Management (802.1ag_. Логично? Логично. Если есть механизм, то почему бы его не использовать?
Что это означает на практике? На практике это означает, что для каждого PBT-туннеля есть возвратный, который идет точно по тому же пути и несет возвратные CFM-фреймы. Как я понял из описания, этот туннель не рабочий, и полезный трафик по нему не идет. Что из этого следует? Правильно. Из этого следует, что мы еще раз удвоили forwarding state.
Что это означает еще? Это означает серьезную нагрузку на CPU как head end'а, так и tail end'а. Чтобы получить переключение в пределах 50мс, мы должны проверять прохождение трафика примерно каждые 10мс. Причем мониторить надо как первичный, так и защитного путь. В защищенной full mesh сети из, скажем, 1000 узлов, head end должен генерировать, а tail end принимать 200000 пакетов в секунду. Что совсем не мало.
Интересно, доберусь я сегодня до сервисов?
This entry was originally posted in my livejournal
