dobrohost писал(а):Ну увы их топографии я не знаю
брр.... я разве не правильно понял что роутеры C и D, хосты и свич это твое хозяйство, разве нет ?
dobrohost писал(а):вот так сейчас выглядит конфиг роутера D:
скаже, а что ты хотел сказать вот этим:
dobrohost писал(а):
- Код: Выделить всё
ip prefix-list DobryjHosting-gw-1-in permit 0.0.0.0/24
ip prefix-list DobryjHosting-gw-1-in permit 0.0.0.0/23
а ?
так же не понимаю смысла в препенде:
dobrohost писал(а):
- Код: Выделить всё
route-map DobryjHostingNetwork permit 20
match ip address prefix-list DobryjHosting-ddos-hole
set as-path prepend 200
dobrohost писал(а):исправил прописав его в конфиг зебры ip route 194.15.127.4/32 eth0
в зебре все обязательно должно быть описано, все ипы, все статик маршруты.
на хосте 194.15.127.4 есть какие то ипы помимо этого ?
dobrohost писал(а):Мне почему то казалось что quagga сама должна это сделать
"само" оно ничего не делается, все нужно делать руками, только так ты получишь сеть с пониманием того как она функционирует
dobrohost писал(а):но сути это не поменяло хост как работал на выход через первый роутер так и работает:
ну а с чего хосту 194.15.127.4 ходить по другому ? иначе чем написано у него в def gw ?
анонсируя /32 маршрут с роутера D на роутер С и B ты их просишь при получении входящего трафика для 194.15.127.4/32 передать трафик на роутер D, но это никак не повлияет на то как сам этот хост отправляет трафик.
dobrohost писал(а):и всё бы ничего если бы хост оставался доступен снаружи (бог с ним что исходящий идёт через первый роутер) задача то отправить на фильтрацию входящий трафик (он то перетекает) но вот хост становится не доступен и трасса к нему рвётся именно на роутере D
ну а что показывает tcpdump на роутере D? ты его смотрел ?
dobrohost писал(а):что бы трафик с того хоста который переведён на роутер D (в нашем примере 194.15.127.4) и шёл на роутер D
входящий извне у тя уже должен ходить через роутер D, из-за анонса /32, а вот исходящий этого хоста пустить через роутер D можно только подняв например OSPF на этом хосте, а с роутера C и роутера D анонсить дефолт с разной метрикой.
dobrohost писал(а): увы я не знаю какими средствами этого добится но мне так думалось что роутер С в состоянии как то редиректить трафик и переадресовывать его на роутер D
чтобы понять тебе нужно разобраться в процессе маршрутизации, в том что и как происходит при получении пакета роутером
а происходит следущее:
роутер получая пакет, в котором есть SRC и есть DST смотрит в свою таблицу маршрутизации на предмет того как достичь этого DST.
В твоем случае когда 194.15.127.4 отправляет пакет то SRC это он сам, а DST это хост например в Инете. Так вот с чего роутеру C пересылать такой пакет на D, если DST по его таблице маршрутизации находится не за D ?
dobrohost писал(а):P.S. я повторюсь что по сути не столь важно куда пойдёт исходящий трафик (если он идёт через роутер С то главное сохранить работоспособность хоста)
так важно или нет
ты уж определись.если не важно как сам 194.15.127.4 ходит в инет, а важно как из инета пакет достигает 194.15.127.4, то своими действиями с анонсом /32 ты уже этого добился. Смотри почему входящий пакет застревает на D.
dobrohost писал(а):А подскажите как это сделать?
с линухом мы не дружим, на FreeBSD это делается через sysctl
dobrohost писал(а):Мне так кажется что мою проблему решит или "Умный свитч" умеющий BGP или же ещё один роутер установленый на стык между роутерами C и D и свитчем, правильно ли я предпологаю?
нет
dobrohost писал(а):следующий вопрос такого плана реально ли будет подружить Роутеры C и D с этим свитчем с целью управления исходящим трафиком?
прочти то что я написал выше про то, как происходит процесс маршрутизации
dobrohost писал(а):Сразу оговорюсь по поводу девайса Cisco С3570 , да он умеет BGP но увы для моих масштабов он дорог
всегда можно купить Б/У железку
dobrohost писал(а):Вот появилась возможность завладеть железкой аля Cisco WS-C3550-48-EMI
ну и нафиг тебе 100-мбитный свич ?
