prohoji Опубликовано 17 сентября, 2015 · Жалоба Добрый день! Сразу извиняюсь за глупый вопрос. Есть вот такая сетка: Сейчас весь трафик между ядром и бордером ходит через шейпер. Т.е. как из интернета в локалку, так и из локалки в интернет. Шейпер (линуксовый сервак с кваггой) анонсирует в ядро дефолт с бОльшим локал-преференсом и поэтому трафик от абонентов ходит именно через него в обход прямого линка. Аналогично шейпер анонсирует в бордер маршруты до локальной /22 сетки с большим локал преференсом и поэтому трафик к абонентам идет от бордера в ядро именно через шейпер. Таким образом если шейпер падает, то трафик от и к клиентам начинает просто ходить по прямому линку. Сейчас возникла необходимость пустить одну /24 сетку в обход шейпера. И тут возник затык. Допустим я анонсирую одну /24 сетку из ядра прямо в бордер. Входящий трафик пойдет мимо шейпера. А как быть с исходящим? Дефолт то у меня анонсируется один. Просто нужный выбирается путем установки локал преференса. Знаю, что вопрос глупый. Но я над ним уже целый день ломаю голову, но ничего кроме как использовать PBR не придумал... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
random7 Опубликовано 17 сентября, 2015 · Жалоба Может быть, довести прямой влан от нужных портов в локалке до 7206? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 17 сентября, 2015 · Жалоба 1. PBR 2. Стерменировать сеть прямо на border-е, пустив через все устройства тупо L2. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
prohoji Опубликовано 17 сентября, 2015 (изменено) · Жалоба По l2 не получится т.к. /24 сетка нарезана на кучку /30 - /28 сетей. Плюс между сетками ходит много трафика. Так что тащить это все на бордер не очень хочется. Изменено 17 сентября, 2015 пользователем prohoji Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vop Опубликовано 17 сентября, 2015 · Жалоба Если терменировать на бордере, что будет при падении прямого линка между ядром и бордером? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
random7 Опубликовано 17 сентября, 2015 · Жалоба В 3750 вроде должен быть VRF - не поможет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MonaxGT Опубликовано 17 сентября, 2015 · Жалоба А если кинуть GRE и анонсить через него? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
random7 Опубликовано 17 сентября, 2015 · Жалоба ещё вариант: "Вы не должны этого хотеть" (с) в смысле, откуда вообще такая необходимость? если у сервера не хватает производительности, то этого не должно быть: линукс на не очень древнем железе всяко быстрее 7206 если клиенты не хотят видеть лишний хоп в трейсе, то можно отредактировать ttl вопрос устойчивости к отказу сервера тоже вроде бы решён Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
prohoji Опубликовано 17 сентября, 2015 · Жалоба К сожалению возможности поменять оборудование нет. Специфика организации такова, что этот процесс растянется но длительное время. А завести такую схему надо уже сейчас. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 17 сентября, 2015 · Жалоба Проще всего таки VRF тогда. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SUrov_IBM Опубликовано 17 сентября, 2015 · Жалоба Prohoji, доброго времени суток. Форумчанин «Vurd», посоветовал Вам практически безотказное и простое решение. Если в Вашей схеме, нет возможности L2 терминирования подсети на border’е, в силу её фрагментированости, сама собой напрашивается технология Policy-based Routing (PBR). На мой взгляд, имея под рукой Cisco, этим грех не воспользоваться, хотя это может вызвать дополнительную нагрузку на маршрутизатор. Общая информация о технологии (на русском) - http://habrahabr.ru/post/101796/ Простой пример PBR: На интерфейсе: interface Ethernet X/X ! В случае Вашей схемы – «3750 – локальная сеть (OSPF)» ip policy route-map wifi ! «wifi» - произвольное имя «rout карты». - - - Сообственно «rout карта»: route-map wifi permit 10 match ip address 101 set ip next-hop x.x.x.x ! «x.x.x.x» - IP Вашего border’а, куда нужно завернуть подсеть, минуя 0.0.0.0/0. - - - Описание сети /24 access-list 101 permit ip y.y.y.y 0.0.0.255 any Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 17 сентября, 2015 · Жалоба Здесь у него скорей будет "set ip default next-hop". Я так понимаю проблема именно в том, что части сетей нужно поставить альтернативный маршрут по-умолчанию. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...