Высшаяинженернаяшкола

Здравствуйте!
Игорь Борисович недавно закончил читать курс по сетям 3 семестр и в конце за 3 минуты рассказал про мультихоминг.
С виду все очевидно, но на практике работает не так как я ожидал, помогите разобраться.

Есть маршрутизатор 2811 + HWIC-4ESW.
Два провайдера zet и sky двумя кабелями воткнуты в fa0/0 и fa0/1 соответственно.
fa0/0/0 привязан к vlan 500 смотрит в LAN. Локальная сеть одна.
Задача - настроить доступ в интернет по обоим каналам одновременно с баллансировкой нагрузки (хотя бы простой 50 на 50, без анализа задержек и пропускной способности) при условии, что один из провайдеров дает нам ip-адрес из приватного диапазона.

Вот полный конфиг, делал как показывал Игорь Борисович:
======================================================================================
Building configuration...
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
boot-start-marker
boot-end-marker
!
logging message-counter syslog
logging buffered 4096
!
no aaa new-model
!
dot11 syslog
ip source-route
!
ip cef
!
ip domain name home
ip name-server 156.154.70.22
ip name-server 156.154.71.22
no ipv6 cef
!
multilink bundle-name authenticated
!
voice-card 0
!
username user privilege 15 secret 5 #%$@f
archive
log config
hidekeys
!
ip ssh version 2
!
interface FastEthernet0/0
mac-address 001c.1cc2.e726
ip address 10.189.8.20 255.255.252.0
ip access-group fa0/0_out out
ip nat outside
ip virtual-reassembly
no shutdown
duplex auto
speed auto
!
interface FastEthernet0/1
mac-address 001c.1cc2.e727
ip address 94.19.254.10 255.255.255.0
ip access-group fa0/1_out out
ip nat outside
ip virtual-reassembly
no shutdown
duplex auto
speed auto
!
interface FastEthernet0/0/0
switchport access vlan 500
!
interface FastEthernet0/0/1
!
interface FastEthernet0/0/2
!
interface FastEthernet0/0/3
!
interface Vlan1
no ip address
!
interface Vlan500
ip address 192.168.0.1 255.255.255.0
ip nat inside
ip virtual-reassembly
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 FastEthernet0/1 94.19.254.1
ip route 0.0.0.0 0.0.0.0 FastEthernet0/0 10.189.8.1
no ip http server
no ip http secure-server
!
!
ip nat inside source route-map skymap interface FastEthernet0/1 overload
ip nat inside source route-map zetmap interface FastEthernet0/0 overload
!
ip access-list standard aclnat
permit 192.168.0.0 0.0.0.255
!
ip access-list extended fa0/0_out
permit ip any any log
ip access-list extended fa0/1_out
permit ip any any log
!
!
route-map zetmap permit 10
match ip address aclnat
match interface FastEthernet0/0
!
route-map skymap permit 10
match ip address aclnat
match interface FastEthernet0/1
!
control-plane
!
line con 0
logging synchronous
line aux 0
line vty 0 4
login local
transport input ssh
!
scheduler allocate 20000 1000
end
======================================================================================
Я ожидал, что при таких настройках пакеты маршрутизируются в тот интерфейс, в адрес которого они NATятся
(или наоборот NATятся в адрес того интерфейса в который смаршрутизированы), но все оказалось не так:
...
May 9 00:32:50.081: %SEC-6-IPACCESSLOGP: list fa0/0_out permitted tcp 94.19.254.10(0) -> 74.125.39.101(0), 1 packet
May 9 00:32:53.093: %SEC-6-IPACCESSLOGP: list fa0/0_out permitted tcp 10.189.8.20(0) -> 209.85.135.102(0), 1 packet
May 9 00:33:03.081: %SEC-6-IPACCESSLOGP: list fa0/1_out permitted tcp 10.189.8.20(0) -> 74.125.53.113(0), 1 packet
May 9 00:33:44.689: %SEC-6-IPACCESSLOGP: list fa0/1_out permitted tcp 94.19.254.10(0) -> 66.102.9.103(0), 6 packets
...
Сразу надо сказать, что если бы оба внешних интерфейса имели бы внешние ip адреса, то проблема была бы не столь острой,
ведь по сути разницы нет с какого интерфейса уйдет во внешний мир пакет, важно то, что ответ вернется назад по адресу источника,
а при трансляции уже была создана запись на нужном интерфейсе с соответствующим адресом, но тем не менее,
Игорь Борисович рекомендовал ставить ACL на out на внешний интерфейс с запретом выхода из него всех пакетов с адресами источника не как у этого интерфейса...
Да и хотелось бы все-таки иметь возможность работы в такой схеме где один провайдер дает ip адреса из приватного диапазона.


??????????????????????????????????????????????????????????????????????????????????????
Возникают вопросы:
1. В чем смысл route-map применимо к NAT?
2. В чем смысл match interface в каждом route-map?
3. Объясните, пожалуйста, поэтапно как пакет обрабатывается в данной схеме от приема из LAN до отправки наружу, что сначала NAT или выбор маршрута?
4. Как сделать так, чтобы пакеты уходили с в нешних интерфесов только с адресами источника конкретно этих самых интерфейсов
(не в смысле как резать все остальные пакеты, а чтобы логика работы была такой)?
??????????????????????????????????????????????????????????????????????????????????????


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

1) Сначала я думал следующим образом (принимая во внимание строки match interface в route-map'ах) -
пришел пакет на внутренний интерфейс от компьютера 192.168.0.100 с адресом назначения 74.125.39.101,
дальше его надо смаршрутизировать, но в таблице маршрутизации нет явных маршрутов, зато есть два default gateway,
значит случайным (или другим) образом выбирается next-hop и соответствующий исходящий интерфейс (допустим выбрался fa0/1),
в настройках исходящего интерфейса есть ip nat outside, следовательно смотрим строки относящиеся к NAT, первая в конфиге
ip nat inside source route-map skymap interface FastEthernet0/1 overload
соответственно смотрим route-map skymap
route-map skymap permit 10
match ip address aclnat
match interface FastEthernet0/1
match ip address aclnat - true, потому что пакет пришел из LAN с адреса 192.168.0.100
как я понимаю пакет мы уже поставили в очередь на исходящий интерфейс fa0/1 и значит match interface fa0/1 - true
соответственно route-map дает permit и происходит трансляция в адрес fa0/1, создаются соответствующие записи в таблице NAT, и пакет стоящий в очереди fa0/1 с него же уходит.

Теперь допустим для этого же пакета выбрался не fa0/1, а fa0/0 в качестве интерфейса отправления
в настройках fa0/0 тоже есть ip nat outside, смотрим
ip nat inside source route-map skymap interface FastEthernet0/1 overload
заходим в route-map skymap
и у нас по идее должно не совпасть match interface fa0/1, соответственно route-map не дает permit и,
(вообще по документации route-map применяется _ТОЛЬКО_ к входящим пакетам _ДО_ выбора исходящего интерфейса и тут я в замешательстве)
как я думал, строка
ip nat inside source route-map skymap interface FastEthernet0/1 overload
пропускается и должен происходить просмотр следующей строки
ip nat inside source route-map zetmap interface FastEthernet0/0 overload
где уже все match совпадают и пакет вроде как должен правильно уйти с fa0/0 с адресом источника fa0/0

Но на деле, как вы можете видеть, все не совсем так.

2) Если не так, значит наоборот - "Сначала NAT, затем маршрутизация" и рассуждать можно так:
пришел пакет на внутренний интерфейс от компьютера 192.168.0.100 с адресом назначения 74.125.39.101,
на интерфейсе vlan 500 на который пришел пакет есть ip nat inside, значит пакет нужно NATить, смотрим
ip nat inside source route-map skymap interface FastEthernet0/1 overload
заходим в
route-map skymap permit 10
match ip address aclnat
match interface FastEthernet0/1
и натыкаемся на _match interface_, но для пакета еще не выбран ни один исходящий интерфейс, так как мы условились что маршуртизация после NATа,
следовательно route-map не дает permit и строка
ip nat inside source route-map skymap interface FastEthernet0/1 overload
пропускается, равно как и следующая строка
ip nat inside source route-map zetmap interface FastEthernet0/1 overload

а раз так, то NAT не происходит и вообще непонятно что и как дальше...

И что есще интересно - все по нулям (то есть в route-map не происходит совпадений с match !?):
route-map zetmap, permit, sequence 10
Match clauses:
ip address (access-lists): aclnat
interface FastEthernet0/0
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map skymap, permit, sequence 10
Match clauses:
ip address (access-lists): aclnat
interface FastEthernet0/1
Set clauses:
Policy routing matches: 0 packets, 0 bytes
======================================================================================

======================================================================================
Теперь эксперименты:

Если убрать match interface в route-map'ах, то трансляция адресов происходит _только_ в адрес fa0/1, так как первой идет строка:
ip nat inside source route-map skymap interface FastEthernet0/1 overload
но при этом пакеты физически уходят с обоих внешних интерфейсов, значит match interface что-то все-таки дает (но ЧТО?).

Если попробовать использовать match next-hop, то по результатам - это равносильно match interface

Если попробовать явно указывать исходящий интерфейс командой set default interface
результат тот же:
May 9 15:22:23.153: %SEC-6-IPACCESSLOGP: list fa0/0_out permitted udp 10.189.8.20(0) -> 156.154.70.22(0), 1 packet
May 9 15:22:33.097: %SEC-6-IPACCESSLOGP: list fa0/1_out permitted udp 10.189.8.20(0) -> 156.154.70.22(0), 1 packet
May 9 15:23:02.125: %SEC-6-IPACCESSLOGP: list fa0/1_out permitted tcp 94.19.254.10(0) -> 91.213.196.100(0), 1 packet

Если просто удалить один route-map, например zetmap (напомню, что zet - это fa0/0 и 10.189.8.20, а sky - fa0/1 и 94.19.254.10), то
с fa0/1 пакеты уходят только с адресом источника 94.19.254.10,
а с fa0/0 - либо с адресом источника 94.19.254.10 либо с 192.168.0.100
======================================================================================

Что я только не пробовал с route-map'ами делать...
Ответьте, пожалуйста, на вышеприведенные вопросы или дайте ссылок на первоисточник, где это подробно описывается,
по сайтам cisco ползал вчера весь день и пол-ночи, почти ничего конкретно по этой проблеме не нашел.

Извините за то, что много понаписал. :)
Спасибо!

Добрый день!
при PBR ваша железка встанет очень скоро, какие у вас каналы?
О балансировке нагрузки PBR можно теоритизировать, но не на каналах в десятки мбит.
Без PBR можно решить вашу задачу с помощью ip sla + floating routes, и тем же способом можно сделать какую-никакую балансировку, разве что треков придется поднять несколько.
Если чего непонятно, спрашивайте.

Вот что нашел - https://www.cisco.com/en..._Chapter.html#wp1057136
...
dropping of packets behavior is seen when static routing is used to connect to multiple ISPs from the same router, PfR uses static routing to control the traffic class routing, and one or more of the ISPs use Unicast Reverse Path Forwarding (Unicast RPF) filtering for security reasons.
...
The solution involves a minimal configuration change with a new keyword, oer, that has been added to the ip nat inside source command. When the oer keyword is configured, new NAT translations are given the source IP address of the interface that PfR has selected for the packet and PfR forces existing flows to be routed through the interface for which the NAT translation was created.

Настраивал по мануалу:

key chain PFRchain
key 1
key-string PFRstring

oer master
logging
border 10.10.10.10 key-chain PFRchain
interface Vlan500 internal
interface FastEthernet0/1 external
interface FastEthernet0/0 external

oer border
local Loopback1
master 10.10.10.10 key-chain PFRchain

interface Loopback1
ip address 10.10.10.10 255.255.255.255

ip route 0.0.0.0 0.0.0.0 FastEthernet0/1 94.19.254.1
ip route 0.0.0.0 0.0.0.0 FastEthernet0/0 10.189.8.1

ip nat inside source route-map skymap interface FastEthernet0/1 overload oer
ip nat inside source route-map zetmap interface FastEthernet0/0 overload oer

route-map zetmap permit 10
match ip address aclnat
match interface FastEthernet0/0

route-map skymap permit 10
match ip address aclnat
match interface FastEthernet0/1


Абсолютно без изменений, как улетали пакеты куда угодно так и продолжают. Пробовал также и вместе с PfR делать route-map dummy как вы писали - эффект такой же как и в первом случае, все начинает ходить только через fa0/0 с адресом fa0/0.

Интересно, что же я не доделал-то с PfR... Явно ведь здесь решение задачи.

Дали вы мне печенюшек похрустеть... =)
К сожалению, проверить смогу только поздно вечером, но у меня уже есть вопрос:
Такой схемой мы создали 4 маршрута, и, если я правильно понимаю, решение о том, в какой из них будет отправлен пакет будет основано уже на адресе назначения - эдакая псевдобалансировка в противоположность по типу как пускать половину локалки через один интерфейс, а вторую через второй с переключением на другой в случае падения? Если так, то нет уж извольте, это не решение, а подпорка. :) Но вы мне дали очень интересную мысль, спасибо!

Игорь,
1) вы действительно полагаете, что 2811 поддерживает "CEF-switching с NAT, то она поддерживает и CEF-switching c PBR"
2) Вы все-таки потестируйте предложенное вами решение, если сразу не видите промах
3) ссылки на необходимость CDP в студию? Вообще говоря, команда позволяет опираться на состояние трэка ( www.cisco.com/en/...gtpbrtrk.html#wp1057830 ), чтобы не заворачивать трафик вслепую.

4) Когда round-robin стала нормальной балансировкой, источники, если есть? На мой взгляд, а так же очень авторитетных людей в мире Cisco, основной недостаток ее будет несвоевременное прибытие пакетов и их внеочередность, что не понравится даже такому неприхотливому протоколу как TCP. А с учетом включенного НАТа, любопытно будет поведение сервера в инете, установившем соединение с хостом А, но получившим АСК от хоста В, вам не кажется?
Не понимаю, к чему вы заговорили о том, что ip sla не занимается балансировкой, она занимается отказоустойчивостью, на случай падения какого-либо канала
OER тяжела и громоздка, более есть более красивые решения, учитывая www.cisco.com/en/..._oerstr.html#wp1059322, хотя последнее наверняка можно как-нибудь обойти

5) Что есть "настоящая балансировка" в вашем понимании?

<blockquote id="quote"><font size="1" face="Verdana, Helvetica, Arial" id="quote">quote:<hr height="1" noshade id="quote"><i>Originally posted by Shek</i>
<br />разделение потоков на основании адресов источника или назначения в данном случае я балансировкой не считаю, задача в другом).
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
хм, вообще при настройка по-умолчанию, СЕФ делает балансировку на основе source and destination полей пакета ;)
а что вы считаете балансировкой? и в чем задача?


Всего хорошего

Так ведь оно изначально по умолчанию и работает ip cef и per-destination, балансировка работает без NATa и PBR, по умолчанию как только появляются два дефолтных маршрута.

Копал PfR и наткнулся совсем на непонятную штуку - когда пишешь
ip nat inside source route-map mapname interface XXX overload и хочешь добавить oer как рекомендуют в документации, то в контекстной справке написано, что приписку oer можно использовать только с virtual-template интерфейсами... Совсем не понимаю что это и зачем нужно, а главное как это использовать в данном случае.

Качал с торрентов это:
c2800nm-adventerprisek9-mz.124-24.T2.bin
ASK9-AESK9 FEAT SET FACTORY UPG FOR BUNDLES

Скажите, а вот это совсем сейчас не в тему или таки стоит покопать? А то я с первой бутылки кефира не разобрался... www.cisco.com/en/.../gtnatvi.html#wp1027357

Почему у нас не так как говорит cisco про то как работает NAT!? Никакой маршрутизации после NAT'а www.cisco.com/en/...e09186a0080133ddd.shtml

Чувствую пора бомбить техсаппорт cisco [8D]

Как дела с тестами? У меня так и не получается...

Сколько же сил было потрачено почти зря.
Оказывается во всем виновато слово log, а точнее то, что в ACL попадающий под ACE с log пакет обрабатывается как process switching.
Так что убираем permit ip any any log и все работает как в аптеке, проверено на рабочей конфигурации!
www.cisco.com/web...igence/acl-logging.html

Благодарности сюда: sysadmins.ru/topic267947.html