|
ru.cisco
- RU.CISCO ---------------------------------------------------------------------
From : Mark A Bernadiner 2:5020/400 25 Oct 2006 06:42:11
To : Sergey Kostenko
Subject : Re: 2 Провайдера
--------------------------------------------------------------------------------
"Sergey Kostenko" <Sergey.Kostenko@p33.f2208.n5020.z2.fidonet.org>
сообщил/сообщила в новостях следующее:
news:1154105748@p33.f2208.n5020.z2.ftn...
> Hello Denis!
>
> Я понял, спасибо. Иными словами, баг наблюдаю не я один и исправлен он или
нет,
> не ясно.
:
-)
да нет никакого бага.
надо просто немного подумать, и можно догадаться, что все правильно,
при рассуждениях считать, что таблица nat общая,
и подмена адресов в пакете, который пришел на интерфейс nat inside
происходит до того, как сработает policy-routing и независимо от того,
на какой интерфейс nat outside будет передан пакет.
просто, вероятно, эту задачу нужно решать другим способом.
например, таким, каким она решена мною
т.е. vrf + route map + свой нат внутри каждого vrf
сеть каждого провайдера включить в свой vrf,
свой нат в каждом из этих vrf,
никакого ната вне этих vrf
> По конфигу... В дальнейшем ACL изменятся и станут "per user" или "per
subnet".
> Приведенный конфиг упрощен для отладочных целей.
>
> Thursday July 27 2034 21:01, Denis V. Schapov. wrote to Sergey Kostenko:
>
> DS> From: "Denis V. Schapov." <dschapov@dsi.ru>
>
> >> Вопрос неоднократно поднимался, но однозначных ответов не нашел :-(
> >> Ситуация простая: два провайдера, каждый выдает подсеть /30, каждый
> >> роутит только свои адреса. Оба провайдера ненадежны (моск. область).
> >> Применяется динамический HАТ сети /24 в один адрес на интерфейсе,
> >> подключенный к провайдерскому коммутатору и статический роутинг.
> >> Маршруты переключаются,
> DS> но!
> >> пока не очистится таблица HАТ-а в сторону упавшего провайдера,
> >> трафик не
> DS> идет в
> >> сторону другого.
> >> Коллеги, подскажите, где что не так...
>
> DS> Аналогично CSCsc21417
>
> DS> CSCsc21417 Bug Details
> DS> Headline OER does not work with NAT
> DS> First Found-in Version 12.3T, 12.4T, 12.4
> DS> First Fixed-in Version 12.4(7.12), 12.4(7.11)T
> DS> Release Notes
>
> DS> Symptom:
> DS> Application flows may dropped/terminated if OER, NAT, and static
> DS> routing to multiple ISPs.
>
>
> DS> Conditions:
> DS> OER, NAT, and static routing to multiple ISP connections with
> DS> different public addresses must be configured.
>
>
> DS> <skip>
>
> DS> Further Problem Description:
> DS> NAT and routing operate independently. NAT will replace
> DS> a private address with a public address on an outgoing packet.
> DS> Routing will route the packet according to the RIB/CEF. If the
> DS> route has changed between when the NAT translation was created
> DS> and when this outgoing packet is transmitted, Reverse Path Forwarding
> DS> (rpf) filtering at the ISP will likely drop the packet. Since OER
> DS> changes routes to optimize performance and load, the likelyhood of
> DS> this occuring is greater than previous multi-homed NAT setup.
>
>
> DS> Hадо будет глянуть, что тут починили.
> DS> Так сказать action plan
>
> DS> 1. Ставьте последний 12.4M/12.4T и проверяйте.
> DS> Если ничего не поменялось с NAT/PBR или апгрейд неприемлем, то
>
> DS> 2. Через IP SLA/SAA MIB ловить трапы по SNMP и ходить by
> DS> telnet/rcmd/snmp и чистить nat translation table, заодно и clear ip
> DS> cache (зависит от версии IOS)
>
> DS> или
>
> DS> 3. Hастроить агрессивный FS cache/NAT table aging, timeouts
>
> DS> или
>
> DS> 4. Открывать кейс в Cisco, имея сервисный контракт, и спрашивать TAC,
> DS> почему так :)
>
> DS> Hачиная с 12.3(4)T, создание entry в NAT table сделали через CEF, с
> DS> последующим свитичнгом через CEF.
> DS> По идее, изменение RIB, вызванное работой PBR и(иди) object tracking,
> DS> должно отразиться в adjacency table и проапдейтить NAT table. Можно
> DS> также попробовать использовать вместо match interface, match
> DS> ip next-hop в route-map для NAT. От PBR на input интерфейсе можно
> DS> отказаться, а между аплинками разруливать на этапе
> DS> NAT
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note
> DS> 09186a0080 093fca.shtml
http://www.cisco.com/en/US/tech/tk648/tk361/te
> DS> chnologies_tech_note09186a0080
> DS> 093fca.shtml#n2
>
> DS> P.S. Смотря на приведенный конфиг, остается вопрос, зачем
использовать
> DS> PBR object tracking, когда в данном случае все решается с помощью
> DS> static route tracking + NAT с использованием route-map, где
> DS> проверяется next-hop из RIB и выбирается соответствующий
> DS> адрес/интерфейс, из-под которого делать трансляцию. Такой конфиг
имеет
> DS> смысл только в том случае, если нужно принимать решение о NAT и
выходе
> DS> через тот или иной аплинк per user. У вас же Acl идентичным, то есть
> DS> класс пользователей всего 1. Всех либо на аплинка 1, либо на аплинка
> DS> 2.
>
> Sergey
>
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
