dovecot Опубликовано 26 января, 2012 · Жалоба Всем привет! Одним из методов управления трафиком (инженерия) в MPLS облаке является создание туннелей. Опираясь на протокол RSVP возможно гарантировать (как бы) некую пропускную способность для туннеля на всем пути в облаке. Также существует еще много интересных "фишек" (FastReRoute, ...). В этом направлении интересует несколько вопросов: 1. Допустим имеем маршрутизатор и два аплинка (20М и 10М). По умолчанию (с таблицы маршрутизации) трафик уходит в линк №1. При трафике >20M будем иметь потери на интерфейсе. Возможно ли опираясь на функционал MPLS реализовать такую вещь: при трафике <15М - загружаем линк №1, все что >15М - отправляем в линк №2. Слышал про такую вещь как MPLS auto-tunnels - это где-то близко? 2. Допустим имеем маршрутизатор, который до документам может пропустить через себя до 200М. В него включены два линка по 500М каждый. Каким образом корректнее задать значения пропускной способности для RSVP на интерфейсе, если при написании доп. ACL, включении QoS и других вещей будем иметь деградацию по производительности. Конечно, можно задать два по 50М, но таким образом сами будем не догружать оборудование. Может у кого-то есть интересные решения/опыт управления трафиком в MPLS сети? Заранее спасибо! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pliskinsad Опубликовано 27 января, 2012 · Жалоба 1) имхо нет 2) уменьшить bandwith в контексте rsvp для интерфейса (поставить 20%). НО! rsvp-te это чисто control-plane понятие, если погнать больше трафика через этот lsp то он пройдет, необходимо где-то отполисить\отшейпить поток до 200. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
triam Опубликовано 27 января, 2012 · Жалоба 1) Точно нет. Тунели они для того, чтобы если через этот линк не проходит, переложить на другой линк, в который проходит, но без потерь трафика. Авто-тунели - это средство призванное автоматизировать процесс прописывание RSVP-тунелей =) Вообще механизмы MPLS-TE обычно применимы только в нутри собственной сети (AS-ки) 2)А вот ограничить прохождение трафика через маршрутизатор можно, но для этого надо знать какой трафик откуда и куда ходит =) (Тут хорошо визуализирует это Auto-tunnel'и). Если нарисуете схему сети можно будет чего-нибудь придумать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bokl Опубликовано 27 января, 2012 · Жалоба для начала советовал бы понять принцип работы MPLS TE где он работает и зачем оно нужно. Даже на LDP для начала. что бы не было глупых вопросов. и надо понимать что всех этих вкусностей не стоит ожидать на энтерпрайз железках. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmvy Опубликовано 27 января, 2012 · Жалоба MPLS-транспорт, а маршрутизация - уже более высокий уровень коммутации. на сколько понимаю, балансировка должна осуществляться инструментами BGP. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dignity Опубликовано 27 января, 2012 · Жалоба Мне кажется, что заботу автора можно решить QoS, маркировкой по полисингу и PBR. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
triam Опубликовано 27 января, 2012 · Жалоба Мне кажется, что заботу автора можно решить QoS, маркировкой по полисингу и PBR. Согласен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...