Я уже написал про MPLS вообще, про LDP, про RSVP-TE. Теперь мы плавно подошли к моей любимой штуке - LDPoverRSVP. Довольно тяжелая для понимая вещь. Давайте разбираться вместе.
Тут важно понимание, зачем вообще нужен такой изврат. А нужен он вот для чего. Мы помним, что MPLS работает поверх IP сети. Связность в этой сети обычно обеспечена TE протоколом динамической маршрутизации (OSPF TE или IS-IS TE). Сеть может быть довольно большой, а в Link-State протоколах маршрутизации принято дробить сеть на зоны. Понятия зон в IS-IS и в OSPF немного отличаются, можете посмотреть серию видео об этом от Let's Lab. Разделение на зоны позволяют сократить накладные расходы на вычисление наилучших путей, вводят возможность суммаризации префиксов на границах зон. Короче, штука эта важная и полезная. Скорее всего, в большое сети разделение на зоны будет присутствовать. По крайней мере, на это стоит надеяться.
Представим упрощенную сеть с зонами на которой запущен OSPF-TE.
Все посты про MPLS VPN можно посмотреть по тегу MPLS или в обобщающем посте.
Из меня не очень художник, но допустим, нам нужно прокинуть туннель от PE1 до PE2. Сделать мы это можем как минимум тремя способами, от наименее желательного к наиболее.
1. Сигнализировать туннель с помощью простого LDP.
Напомню, что в таком случае, маршрут прохождения туннеля будет определен OSPFом. Про дополнительные механизмы отказоустойчивости типа FRR можно забыть.
2. Сигнализировать туннель с помощью RSVP-TE не прибегая к помощи CSPF. В таком случае маршрут так же будет прокладываться OSPFом. FRR можно будет запустить, если руками определить каждый узел прохождения маршрута hop-by-hop.
3. Сигнализировать туннель с помощью RSVP-TE с использованием CSFP. Думаю, ясно, что этот вариант самый лучший. Мы тут получаем дополнительные плюшки в виде FRR, можем прокладывать туннели без указания узлов и прочее.
Так вот, последний вариант сигнализации без костылей в такой сети работать не будет. Вспомните, ведь дополнительная информация для CSPF передается с помощью протокола OSPF. А она в дизайне с зонами будет оставаться в пределах одной зоны. Таким образом CSPF не сможет просчитать кратчайший маршрут связывающий несколько зон потому что у него не будет никакой информации о соседних зонах. Эта информация есть только у A(S)BR в OSPF или у L1/L2-маршрутизатора в IS-IS.
Конечно, можно в такой топологии строить туннели при помощи LDP или CSPFless RSVP-TE (только что придумал термин), но это как минимум плохо кастомизируется, плохо масштабируется и вообще так себе решение. Вы, как сетевой инженер, должны хотеть получить все плюшки RSVP-TE CSPF!
И тут начинаются костыли... Но довольно красивые, стоит признать.
Обратимся к той же схеме сети.
1. Допустим PE1 сигнализирует туннель с PE2 при помощи T-LDP (pseupowire). Делает он этого для того чтобы передать трафик абонента. После чего PE1 знает с какой меткой стоит передавать трафик, чтобы PE2 понял куда в свою очередь передать трафик этого туннеля. Ок. Теперь надо этот трафик как-то передать через всю MPLS-сеть от PE1 до PE2.
2. Нам ничего не мешает строить RSVP-TE туннели с CSPF внутри зон. Чем мы и займемся. Допустим мы построили туннель от PE1 до ABR1 через R1, аналогичный туннель мы можем построить между ABR1 и ABR2 и между ABR2 и PE2 внутри соответсвтующих зон. Таким образом, в каждой из зон мы получаем все плюсы использования CSPF.
3. Теперь нам нужен костыль. ABR1 как-то должен передать трафик из одной RSVP-TE зоны в другую... хм... можно ведь построить туннель... T-LDP туннель... Ок. Поднимаем T-LDP сессию между PE1 и ABR1, между ABR1 и ABR2 и между ABR2 и PE2.
Давайте проследим весь путь кадра. Тут придется нарисовать аккуратнее.
PE1
К PE1 приходит чистый трафик от клиента, после чего он оборачивает его первой меткой (vc-label) (10). Эта метка дает понять точке выхода PE2 куда отправить чистый трафик. Эта метка имеет значение только для него и она была сигнализирована в результате T-LDP сессии PE1-PE2. PE1 далее навешивает ещё одну метку (transport label) (20), которую ему сообщил ABR1 в результате сигнализирования другой T-LDP сессии. Эта метка важна только для него. И в завершении всей этой вакханалии, PE1 ставит ещё одну метку (назовем её, inter-area) (30). Эту метку ему сказал R1. Она нужна для того чтобы отправить трафик к ABR1 через всю зону с помощью построеного RSVP-TE пути.
R1
Когда трафик придет на R1, он посмотрит в стек меток, увидит там первую "inter-area" метку (30) и узнает её, потому что это он о ней рассказал PE1 с помощью RSVP-TE. Далее он эту метку поменяет на другую "inter-area" метку (31) и отправит в сторону ABR1.
ABR1
ABR1 так же заглянет в стек меток, увидит там первую "inter-area" метку (31) о которой он рассказал R1 в процессе сигнализации RSVP-TE LSP. Далее он эту метку отбросит, потому что он является выходной точкой из RSVP-TE туннеля. Следующая метка, которую он увидит - T-LDP метка (20). Тут как раз и произойдет склеивание двух концов LSP. В нашем случае, ABR1 заменит transport label (20) на другую (21), которую ему сказал использовать его T-LDP коллега ABR2. Т.к. до ABR2 нужно ещё добраться, ABR2 навешивает ещё RSPV-TE метку 40 и отправляет трафик в сторону Core роутера.
Core
Задача ядра проста. Маршрутизатор смотрит в метку полученного трафика (40) и узнает там её, потому что сам рассказал ABR1 какую метку нужно использовать. Затем он просто меняет iner-area метку на другую (41) и отправляет трафик в сторону ABR2.
ABR2
Мы помним, ABR2 должен связать два конца LSP. Т.к. ABR2 является выходной точкой в туннеле, он отбрасывает первую inter-area метку (41). Ведь трафик предназначен ему. Далее, заглянув в стек меток, он увидит там T-LDP метку (21), которую он выделил ABR1 для того, чтобы тот слал трафик к нему. Наш ABR2 убирает её и ставит на её место другую T-LDP метку (22), с помощью которой он отправит трафик PE2. Чтобы использовать всю силу CSPF он испольщует RSVP-TE туннель до PE2. Именно поэтому он навешивает ещё меточку (50). В итоге, трафик с тремя метками покидает интерфейс в сторону R2.
R2
R2 ничего не знает ни о туннелях, ни о T-LDP, ведь он учавствовал только в синхронизировании RSVP-TE туннеля от ABR2 до PE2. Поэтому в пришедшем к нему кадре он меняет верхнюю метку (50) на ту, которая пришла при синхронизации от PE2 (51), и отправляет кадр в сторону PE2.
PE2
PE2 - это выходная точка для 3 туннелей. Во-первых, наш роутер отбрасывает первую RSVP-TE метку (51), которую он назначил для отправки к нему трафика. Во-вторых, он отбрасывает T-LDP метку (transport label) (22), потому что он является точкой выхода и из этого туннеля. В-третьих, он видит самую нижнюю метку (vc-label) (10), которую он сигнализировал с далеким-далеким PE1 для того чтобы передавать VPN трафик абонента. Он отбрасывает и её. После чего отправляет трафик, чистый как слеза, свободный от всяких меток, в сторону абонента.
Ура! А теперь представьте что в ядре будет значительно больше коммутаторов, чем одинокий Сore. Путь от PE1 до ABR1 может пролегать через несколько роутеров, а не через R1. Скорее всего граничный маршрутизаторов ABR будет больше чем один. В таком случае:
1. Каждый PE маршрутизатор должен иметь T-LDP сессию с каждым ABR.
2. Каждый ABR должен иметь T-LDP сессию с каждым другим ABR.
3. Каждый PE роутер должен иметь RSVP-TE туннель до каждого ABR
4. Каждый ABR должен иметь RSVP-TE туннель до каждого ABR.
На случай, если вы где-то налажали, на каждом линке должен быть включен самый обычный LDP, чтобы если уж что-то пошло не так, трафик от PE1 добрался до PE2. Пусть без всяких фишек типа FRR, пусть полагаясь на маршрутную информацию OSPF, но трафик должен достичь PE2.
Кстати о FRR! Допустим роутеров CORE у нас два и мы сигнализировали RSVP-TE туннель между ABR1 и ABR2 с Node protection facility backup. Смекаете? В таком случае, ABR1 построит дополнительный туннель до ABR2 через CORE2. И если вдруг CORE1 откажет, то к 3 меткам прибавиться ещё одна, которая будет идентифицировать обходной путь. Итого 4 метки в кадре. Не думаю, что это предел, наверняка можно и ещё что-то замудрить и меток станет ещё больше.
Давайте проследим весь путь кадра. Тут придется нарисовать аккуратнее.
PE1
К PE1 приходит чистый трафик от клиента, после чего он оборачивает его первой меткой (vc-label) (10). Эта метка дает понять точке выхода PE2 куда отправить чистый трафик. Эта метка имеет значение только для него и она была сигнализирована в результате T-LDP сессии PE1-PE2. PE1 далее навешивает ещё одну метку (transport label) (20), которую ему сообщил ABR1 в результате сигнализирования другой T-LDP сессии. Эта метка важна только для него. И в завершении всей этой вакханалии, PE1 ставит ещё одну метку (назовем её, inter-area) (30). Эту метку ему сказал R1. Она нужна для того чтобы отправить трафик к ABR1 через всю зону с помощью построеного RSVP-TE пути.
R1
Когда трафик придет на R1, он посмотрит в стек меток, увидит там первую "inter-area" метку (30) и узнает её, потому что это он о ней рассказал PE1 с помощью RSVP-TE. Далее он эту метку поменяет на другую "inter-area" метку (31) и отправит в сторону ABR1.
ABR1
ABR1 так же заглянет в стек меток, увидит там первую "inter-area" метку (31) о которой он рассказал R1 в процессе сигнализации RSVP-TE LSP. Далее он эту метку отбросит, потому что он является выходной точкой из RSVP-TE туннеля. Следующая метка, которую он увидит - T-LDP метка (20). Тут как раз и произойдет склеивание двух концов LSP. В нашем случае, ABR1 заменит transport label (20) на другую (21), которую ему сказал использовать его T-LDP коллега ABR2. Т.к. до ABR2 нужно ещё добраться, ABR2 навешивает ещё RSPV-TE метку 40 и отправляет трафик в сторону Core роутера.
Core
Задача ядра проста. Маршрутизатор смотрит в метку полученного трафика (40) и узнает там её, потому что сам рассказал ABR1 какую метку нужно использовать. Затем он просто меняет iner-area метку на другую (41) и отправляет трафик в сторону ABR2.
ABR2
Мы помним, ABR2 должен связать два конца LSP. Т.к. ABR2 является выходной точкой в туннеле, он отбрасывает первую inter-area метку (41). Ведь трафик предназначен ему. Далее, заглянув в стек меток, он увидит там T-LDP метку (21), которую он выделил ABR1 для того, чтобы тот слал трафик к нему. Наш ABR2 убирает её и ставит на её место другую T-LDP метку (22), с помощью которой он отправит трафик PE2. Чтобы использовать всю силу CSPF он испольщует RSVP-TE туннель до PE2. Именно поэтому он навешивает ещё меточку (50). В итоге, трафик с тремя метками покидает интерфейс в сторону R2.
R2
R2 ничего не знает ни о туннелях, ни о T-LDP, ведь он учавствовал только в синхронизировании RSVP-TE туннеля от ABR2 до PE2. Поэтому в пришедшем к нему кадре он меняет верхнюю метку (50) на ту, которая пришла при синхронизации от PE2 (51), и отправляет кадр в сторону PE2.
PE2
PE2 - это выходная точка для 3 туннелей. Во-первых, наш роутер отбрасывает первую RSVP-TE метку (51), которую он назначил для отправки к нему трафика. Во-вторых, он отбрасывает T-LDP метку (transport label) (22), потому что он является точкой выхода и из этого туннеля. В-третьих, он видит самую нижнюю метку (vc-label) (10), которую он сигнализировал с далеким-далеким PE1 для того чтобы передавать VPN трафик абонента. Он отбрасывает и её. После чего отправляет трафик, чистый как слеза, свободный от всяких меток, в сторону абонента.
Ура! А теперь представьте что в ядре будет значительно больше коммутаторов, чем одинокий Сore. Путь от PE1 до ABR1 может пролегать через несколько роутеров, а не через R1. Скорее всего граничный маршрутизаторов ABR будет больше чем один. В таком случае:
1. Каждый PE маршрутизатор должен иметь T-LDP сессию с каждым ABR.
2. Каждый ABR должен иметь T-LDP сессию с каждым другим ABR.
3. Каждый PE роутер должен иметь RSVP-TE туннель до каждого ABR
4. Каждый ABR должен иметь RSVP-TE туннель до каждого ABR.
На случай, если вы где-то налажали, на каждом линке должен быть включен самый обычный LDP, чтобы если уж что-то пошло не так, трафик от PE1 добрался до PE2. Пусть без всяких фишек типа FRR, пусть полагаясь на маршрутную информацию OSPF, но трафик должен достичь PE2.
Кстати о FRR! Допустим роутеров CORE у нас два и мы сигнализировали RSVP-TE туннель между ABR1 и ABR2 с Node protection facility backup. Смекаете? В таком случае, ABR1 построит дополнительный туннель до ABR2 через CORE2. И если вдруг CORE1 откажет, то к 3 меткам прибавиться ещё одна, которая будет идентифицировать обходной путь. Итого 4 метки в кадре. Не думаю, что это предел, наверняка можно и ещё что-то замудрить и меток станет ещё больше.
Первое время я всё никак не мог понять, почему ABR1, например, меняет transport метку на другую, тем самым склеивая LSP. Ответ прост, потому что ему так говорит Control plane. Он просто имеет запись в своей таблице, которая говорит ему поменять одну метку (от PE1) на другую (от ABR2) и отправить трафик дальше.
Второе, что почему-то не могло найти место в моей голове, это то необходимость строить два тунеля по одному пути. T-LDP тунель от PE1 до ABR1 и RSVP-TE тунель от PE1 до ABR1. Они же сомпадают, вопрошал я. Но дело было в той схеме которую я нарисовал. Она слишком упрощенная. Путь от PE1 до ABR1 может пролегать через много промежуточный роутеров. Тут RSVP-TE строиться для того чтобы наиболее эффективно передать траффик между PE1 и ABR1. А сама "надобность" что ли такой передачи определяет T-LDP сессия между PE1 и ABR1.
Короче, MPLS классный!
Второе, что почему-то не могло найти место в моей голове, это то необходимость строить два тунеля по одному пути. T-LDP тунель от PE1 до ABR1 и RSVP-TE тунель от PE1 до ABR1. Они же сомпадают, вопрошал я. Но дело было в той схеме которую я нарисовал. Она слишком упрощенная. Путь от PE1 до ABR1 может пролегать через много промежуточный роутеров. Тут RSVP-TE строиться для того чтобы наиболее эффективно передать траффик между PE1 и ABR1. А сама "надобность" что ли такой передачи определяет T-LDP сессия между PE1 и ABR1.
Короче, MPLS классный!
Комментариев нет:
Отправить комментарий