Бесчеловечные эксперименты в области стоматологии
Я собирался написать очередной прогон про мультикаст, MPLS, FRR и прочие прикольные штучки. Сел сегодня в лабе, отлабал даже, что хотел. Но, подумав, понял, что писать длинную и подробную байку с картинками, конфигами и детальными объяснениями что, зачем и почему, я не буду - слишком много получится. И решил забить. Потом подумал еще раз, и решил все-таки написать, но тезисно и без подробностей. Если кому-то очень-очень надо, то конфиги дам, но картинки рисовать и описывать каждую строчку конфига не буду.

Итак. Некоторое время назад, я написал сумбурный и путанный пост про защиту мультикаста с помощью MPLS FRR. Это, конечно же, было полное гонево. Там требовалось модифицировать протоколы, изменять алгоритм проверки RPF и т.д. На самом деле, все составные части для того, чтобы сделать защиту мультикаста FRR'ом, уже есть. Во-первых, мультикаст в VPLS, который пропагандирует Алкатель, а во-вторых, routed pseudowires, на которые мое внимание обратил один хороший человек в приватной беседе.

В чем, собственно, идея? Идея очень простая - создать поверх MPLS-сети наложенную топологию из pseudowires, по которой и гонять мультикаст. А эти PW уже можно положить в MPLS TE туннели, которые защитить fast-reroute'ом с соответствующим временем восстановления. FRR будет либо link protection, если PW в точности повторяют физическую топологию, либо node и link protection, если PW лежат не между соседними узлами.

Возникает вопрос, что делать с этими PW дальше, и где будет репликация, и какая. С PW можно делать две вещи. А именно, бриджить между ними и роутить. Соответственно, в первом случае получается VPLS, возможно daisy-chained, во втором - те самые routed pseudowires. А репликация мультикаста, очевидно, будет на стыкующих узлах. В первом случае - L2 репликация со всеми ее приколами: snooping'ом, MVR'ом и прочими прелестями жизни, во-втором случае - L3 multicast routing с PIM'ом.

Чем же я занимался сегодня в лабе. Этим вот и занимался. Наконец, решил попробовать собрать на циске и посмотреть на все это живьем. Одна беда. Для VPLS'а и для routed PW нужны умные карточки в 7600: либо SIP'ы, либо новенькие ES20, а у меня только 6704 и 6748. 6704 - штука, конечно, хорошая, она даже умеет loss of signal миллисекунд за 30 обнаруживать, но для VPLS'а и прочих нужных штук довольно бесполезная. Ну, где наша не пропадала. Как обычно, на помощь пришло оружие пролетариата - hairpin, т.е. проводок, соединяющий два порта одной и той же железки. Берем один порт, вешаем на него xconnect куда надо, а второй, с ним соединенный, либо делаем свитчпортом в каком-то нужном VLAN'е, либо оставляем обычным routed портом и вешаем на него адрес. В первом случае получается бриджинг между PW, если их засунуть в один VLAN, во втором, очевидно роутинг. Благо мультикаста у меня заметно меньше гигабита, то порты на 6748 вполне годятся.

Сыграл я в оба варианта. Оба работают. Рвешь десятигиговый линк - картинка либо вообще не дергается, либо появляется маленький-маленький артефактик, который, если его специально не ждать, то и не заметишь. Еще бы, fast route все-таки.

Какой из вариантов лучше? Оба, на самом деле, плохие. Во-первых, наложенные топологии строить ужасно геморно, просто геморно. Во-вторых, в случае с бриджингом PW надо внимательно следить, чтобы не наделать лупов. Плюс, L2, как обычно, отлаживать тяжело - диагностических средств минимум. В случае с роутингом между PW все тоже весело: надо запускать второй протокол маршрутизации (первый нужен для самого MPLS'а) на наложенной сети, чтобы PIM работал нормально, что тоже не сахар, но зато можно строить произвольную топологию из PW.

У всей этой идеи в обоих ее вариантах есть слабое место - восстановление при гибели узла, который стыкует PW либо с помощью бриджига, либо с помощью роутинга. Что делать?

В случае с бриджингом восстановление от потери узла будет происходить с помощью выбора PIM designated router. Этот процесс можно сделать достаточно быстрым путем выкручивания pim query-interval. Но надо осторожно, слишком сильно выкручивать нельзя. При обрыве линка, когда срабатывает FRR, и трафик идет сильно окольным путем, сообщения PIM'а могут и опоздать. Тогда будет плохо.

В случае с роутингом между PW сходимость будет опираться на сходимость второго IGP. Поскольку второй IGP живет в наложенной сети, то непосредственно увидеть погасшие линки к упавшему узлу он не сможет. Поэтому обнаружение аварии во втором IGP опирается на hello-сообщения. Что не быстро, совсем не быстро. Можно сделать BFD, но опять же надо без фанатизма. Думается, что добиться субсекундной сходимости для гибели узла вполне реально.

Буду ли я делать подобные конструкции в живых сетях? Не знаю. Надо их изучить гораздо внимательней, чем я смог за три часа сегодняшних упражнений. Там есть куча подробностей, которые я даже не упомянул в этом посте. Точно не буду делать с hairpin'ами: криво, ненадежно, непроизводительно - трафик проходит через роутер трижды. С SIP'ами или ES'ками, может быть, но надо много экспериментировать, прежде чем внедрять.