[prohoji]

Добрый день!

 

Сразу извиняюсь за глупый вопрос. Есть вот такая сетка:

 

 

Сейчас весь трафик между ядром и бордером ходит через шейпер. Т.е. как из интернета в локалку, так и из локалки в интернет. Шейпер (линуксовый сервак с кваггой) анонсирует в ядро дефолт с бОльшим локал-преференсом и поэтому трафик от абонентов ходит именно через него в обход прямого линка. Аналогично шейпер анонсирует в бордер маршруты до локальной /22 сетки с большим локал преференсом и поэтому трафик к абонентам идет от бордера в ядро именно через шейпер.

Таким образом если шейпер падает, то трафик от и к клиентам начинает просто ходить по прямому линку.

 

Сейчас возникла необходимость пустить одну /24 сетку в обход шейпера. И тут возник затык. Допустим я анонсирую одну /24 сетку из ядра прямо в бордер. Входящий трафик пойдет мимо шейпера. А как быть с исходящим? Дефолт то у меня анонсируется один. Просто нужный выбирается путем установки локал преференса.

 

Знаю, что вопрос глупый. Но я над ним уже целый день ломаю голову, но ничего кроме как использовать PBR не придумал...

[random7]

Может быть, довести прямой влан от нужных портов в локалке до 7206?

[vurd]

1. PBR

2. Стерменировать сеть прямо на border-е, пустив через все устройства тупо L2.

[prohoji]

По l2 не получится т.к. /24 сетка нарезана на кучку /30 - /28 сетей. Плюс между сетками ходит много трафика. Так что тащить это все на бордер не очень хочется.

Изменено 17 сентября, 2015 пользователем prohoji

[vop]

Если терменировать на бордере, что будет при падении прямого линка между ядром и бордером?

[random7]

В 3750 вроде должен быть VRF - не поможет?

[MonaxGT]

А если кинуть GRE и анонсить через него?

[random7]

ещё вариант: "Вы не должны этого хотеть" (с)

 

в смысле, откуда вообще такая необходимость?

если у сервера не хватает производительности, то этого не должно быть: линукс на не очень древнем железе всяко быстрее 7206

если клиенты не хотят видеть лишний хоп в трейсе, то можно отредактировать ttl

вопрос устойчивости к отказу сервера тоже вроде бы решён

[prohoji]

К сожалению возможности поменять оборудование нет. Специфика организации такова, что этот процесс растянется но длительное время. А завести такую схему надо уже сейчас.

[NiTr0]

Проще всего таки VRF тогда.

[SUrov_IBM]

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

[vurd]

Здесь у него скорей будет "set ip default next-hop". Я так понимаю проблема именно в том, что части сетей нужно поставить альтернативный маршрут по-умолчанию.