On Fri, 19 Mar 1999, Oleg King wrote:
> Hello!
>
> Есть тут некая проблемка. Есть циска, подключенная вот так:
>
>
> нечто (2)
> |
> -----------------
> | i1 |
> users (1) -----|i2 Cisco 3640 |
> | i3 |
> -----------------
> |
> канал на Москву, сервер вовне (3)
>
> Задумка следующая:
>
> На интерфейсе циски i2 поставить такой вот route-map
>
> permit any to any <port>, next hop = (2)
> permit any <port> to any, next hop = (2)
>
> Тогда по идее, если users (1) попутается законнектиться с сервером,
> находящимся вовне, весь траффик при коннекте на <port> должен проходить
> через (2), который может делать с ним все, что угодно (например,
> проверять контент и подставляться сам вместо сервера). На самом же
> деле те пакеты, которые прошли через (2), проходят на настоящий сервер
> через интерфейс i3, ответ возвращается через i3 на i2, там
> разворачивается на (2), проходит через него, возвращается на i2, там
Вот с этого момента - сказка какая-то...
Если route-map стоит на интерфейсе i2, то он никак не может завернуть
пакет, идущий с i3 на i2 в сторону (2)...
> снова разворачивается на (2) и так, пока он не сдохнет из-за TTL.
>
> Вопрос: можно ли как-то на циске поставить route-map in и route-map
> out, и чтобы это были разные route-map? Заморачиваться, выставляя на
Нет, конечно...
> (2) другую precedence и потом рассматривая ее в access-list
> route-map'а почему-то не хочется (криво это).
>
> Вариант поставить route-map на i2 и еще один на i3 не прокатывает,
> потому что если вдруг извне кто-то захочет пройти на <port> юзера,
> заимеем такую же ситуацию. То есть надо в идеале при описании на всех
> интерфейсах поставить вышеупомянутый route-map + правило, что-то типа
> "а если предыдущий хоп роутинга был (2) (пришло с его мак-адреса), то
> туда дальше не роутить". Я слишком оптимист или так и вправду можно
> сделать?
Прежде чем "это" делать, наверное стоит понять, как смогла
получиться ситуация, описанная выше... Если принять, что выше описано
_все_, то это относится к разряду "чудес"... Где-то что-то не рассказано...
Наверное, "конфиг на бочку" + доказательства того, что пакеты идут
с данным конфигом именно так, как описано, помогут в понимании происходящего.
>
--------------------------------------
Basil (Vasily) Dolmatov CCNA,CCDA
East Connection ISP, Moscow, Russia. ()
=============================================================================
"inet-admins" Internet access mailing list. Maintained by East Connection ISP.
Mail "unsubscribe inet-admins" to Majordomo@info.east.ru if you want to quit.
Archive is accessible on
