слишком сложная для меня задачка, нужны советы ;/есть Cisco 26xx, IP Plus, 4 канала к разным провайдерам, AS нет
сетка реальных адресов от первого аплинка и несколько интранет сеток (буду называть их все локальные)
интерфейсы к аплинкам сконфигурированы как vlan'ы на ethernet'e цискиаплинки:
1. основной канал в инет
2. канал в инет и адресному пространству аплинка (пиринг) без маршрутизации моих реальных адресов
3. инет и пиринг с маршрутизацией моих реальных адресов со стороны этого аплинка
4. только пиринг с маршрутизацией моих реальных адресовнужно:
a) направлять абсолютно весь трафик для выбранных локальных адресов через выбранного аплинка
b) направлять трафик для выбранных локальных адресов к выбранным сетям через выбранного аплинка
c) не попавший в вышеописаные условия трафик, для выбранных локальных адресов, направлять через аплинка 1.
d) при падении аплинка 1. отправлять весь "его" трафик через второго аплинка.Частично я эту задачу решил путем использования route-map и статического роутинга нужных сетей через нужных аплинков. Но тут возникает проблема. При отправке запроса к моим реальным адресам из пиринговых сетей, без отдельной маршрутизации с удаленной стороны, трафик приходит через первого аплинка, а уходит через другого, конечно из под NAT'a. Понятно что тут получается.
а конкретнее??
аплинки:
1 fe0/0.2: 192.168.1.1/30
2 fe0/0.3: 192.168.2.1/30
3 fe0/0.4: 192.168.3.1/30
4 fe0/0.5: 192.168.4.1/30реальная сетка выданная 1-м аплинком: 10.1.0.0/24
интранет сетка 1: 10.2.0.0/24
интранет сетка 2: 10.3.0.0/24
адресное пространсво пиринга аплинка 2: 10.0.2.0/24
адресное пространсво пиринга аплинка 3: 10.0.3.0/24
адресное пространсво пиринга аплинка 4: 10.0.4.0/24у аплинков 1, 3, 4 есть роутинг на мою реальную сетку
работать все должно так:
10.1.0.0/24:
destination 10.0.3.0/24 gw 192.168.3.2
destination 10.0.4.0/24 gw 192.168.4.2
destination 0.0.0.0/0 gw 192.168.1.210.2.0.0/24:
destination 10.0.3.0/24 gw 192.168.3.2 nat
destination 10.0.4.0/24 gw 192.168.4.2 nat
destination 0.0.0.0/0 gw 192.168.2.2 nat10.3.0.0/24:
destination 10.0.2.0/24 gw 192.168.2.2 nat
destination 10.0.3.0/24 gw 192.168.3.2 nat
destination 10.0.4.0/24 gw 192.168.4.2 nat
destination 0.0.0.0/0 gw 192.168.1.2 nat
ни у кого идей не появилось?
пиринг, аплинк.. Честно говоря лень втыкать в такую непонятную кашу.Могу сказать слкдующее:
Если нужно хоть какое нибудь резервирование, то статикой не обойтись, нужно поднимать маршрутизацию. Судя по обилию специфических требований нужно использовать BGP.
Мой совет использовать приватную автономную систему и BGP, а там уже проверенными народными способами :)
Хотя есть еще вариант еще раз описать условия задачи разбив ее на относительно независимые части и без злоупотребления словами типа пиринг-аплинк. Может быть тогда все обойдется несколькими простыми OSPF процессами.
использование любого из протоколов маршрутизации приведет к необходимости настройки роутеров у других операторов, но это не входит в планы
>использование любого из протоколов маршрутизации приведет к необходимости настройки роутеров у других
>операторов, но это не входит в планыМаршрутизация это двунаправленный процесс. Вы можете выбирать путь только для исходящего трафика, а вот входящий к вам трафик направляется маршрутизаторами провайдера. Чтобы повлиять на путь ВХОДЯЩЕГО трафика и придуманы всяческие протоколы маршрутизации с помощью которых вы можете "заставить" маршрутизатор провайдера отправлять трафик по нужному вам маршрутам.
Не будет протокола маршрутизации - не будет никаких работоспособных вариантов, даже с двумя каналами.
тут немного потеряна суть проблемы
вопрос: каким способом отправлять исходящие пакеты от определенных адресов по определенным каналам в зависимости от назначения, а то по каким путям пойдут ответы это уже совсем другая проблема
тут даже не стоит брать во внимание проблему NATинга, потому что она решается совершенно отдельно от роутинга, с помощью match interface в route-map
> интерфейсы к аплинкам сконфигурированы как vlan'ы на ethernet'e циски
как тогда ваша циска должна узнать, что канал у какого-то провайдера упал... Ethernet упасть не может, поэтому остается только использовать динамическую маршрутизацию. Или разносите это всё на две отдельные железки.
я это понял, извиняюсь, неточность с моей стороны
тогда исключаем из задачки бэкап канала (если очень будет надо я могу перебросить маршруты скриптом по rshell)
тогда default route на 1го аплинка - остальное делается через policy routing
>тогда default route на 1го аплинка - остальное делается через policy routingа тот трафик, который должен идти к сетям других аплинков через них же, рулить только с помощью policy routing или добавлять ip route?
А как на счет route map + ACL. У меня 2аплинка и route map замечательно с этим справляется.
После того как, я перечитал на 20-й раз статью о policy routing на cisco.com, меня вдруг осенило что в match ip address ... можно использовать не только standard access list, но и extended, где можно четко задать откуда и куда какой трафик идет. Я же пытался решить задачку используя только standard access-list'ы. Как результат, у меня не получалось правильно отфильтровать нужный трафик в route-map.