Странности с nat'ом на роутерах

[smartchecker]

Есть два роутера c2811 и c2911.
Картинка на обоих схожая. На внешний интерфейс прибит 79.134.xxx.aa5, но nat'им внутрь другой ip из того же диапазона.
Как-то так:
ip nat inside source static tcp 172.31.7.11 80 79.134.xxx.aa7 80 extendable

и на 2911 порт пробрасывается нормально, а на 2811 где-то застревает, хотя acl одинаковые.
Где может быть

Comments

[dadv]

Где угодно. Пакеты до внешнего IP могут вообще не доставляться в циску по разным причинам, это надо проверять первым делом. Если пакеты доставляются - они могут фильтроваться ACL на входе. Если не фильтруются - может быть неправильно настроен NAT и пакет может не транслироваться. Если пакет транслируется правильно - может быть проблема с роутингом до внутреннего IP. Если проблемы с роутингом нет, пакет может резаться ACL на выходе из роутера. Если на выходе не режется - пакет может не доставляться внутренней сетью до итогового хоста или фильтроваться этим хостом на входе и так далее.

ping, traceroute, логирование в ACL и/или NAT в зубы и вперед. Ещё полезно отзеркалировать трафик, если есть такая возможность и проверить реальное хождение пакетов.

[smartchecker]

Фишка в том, что, если на 2811 прописать нужный внешний адрес как secondary, то всё начинает работать, а на 2911 работает и без этого.

[dadv]

Значит, дело в первом пункте - в изначальной доставке пакетов для внешнего адреса на циску. Пакеты для IP-адреса могут маршрутизироваться на циску по разным причинам. Например, у аплинка может существовать явный маршрут на такой вторичный IP-адрес через первый. Или циска просто отвечает своим MAC-адресом аплинку на его ARP-запросы об вторичном IP-адресе, когда онг прописан и не отвечает, когда не прописан, а раз не отвечает, то и не получает пакеты для этого адреса.

В любом случае, инструментарий для выяснения окончательного диагноза уже перечислен: ping, traceroute, ACL log, зеркалирование трафика.

[smartchecker]

Дело в том, что своим MAC'ом она овечает и когда прописан, как secondary и когда нет.
Т.е. как только добавляю правило для nat, появляется соотв. MAC

Protocol Address Age (min) Hardware Addr Type Interface
Internet 79.134.xxx.y62 - 0023.0414.e830 ARPA FastEthernet0/0
Internet 79.134.xxx.y65 - 0023.0414.e830 ARPA FastEthernet0/0
Internet 79.134.xxx.y67 - 0023.0414.e830 ARPA FastEthernet0/0

На адрес .y65 secondary прописан на .y67 только static nat.
И ping'и снаружи на него(y67) ходят нормально.
И в acl'ки, на входе, трафик попадает.

[anonymous]

Недавно меняли роутер 2610->2811 на стыке с провайдером и словили ровно то же самое. Выяснилось, что циска 28хх не кидает соседу gratituous arp при подключении порта для тех адресов, которые ей натятся, но не висят непосредственно на интерфейсе. В результате при замене циски у аплинка для "интерфейсного" ip-адреса arp-запись обновляется, а для "натящегося" - остается закешированный старый мак, и трафик на этот адрес до твоей циски не доходит, пока не протухнет/не почистят arp-кэш у аплинка.
Я в такой ситуации выкрутился так - временно повесив "натящийся" адрес на интерфейс, передернул линк, а потом вернул всё как было.

[smartchecker]

Так, ещё раз для тупых :)
Какая последовательность действий?

[lost_infidel]

2900 снять и выключить.
Поставить на 2800 адрес y67 на интерфейс (можно даже без ната), адрес y65 убрать вообще.
Перезагрузить роутер или мигнуть линком, тем самым аплинку прислать gr.arp со своим маком на этот адрес.
Убедиться, что теперь от y67 пингается шлюз аплинка.
Вернуть на 2800 исходный конфиг, снова мигнуть линком (у аплинка пропишется верный мак и для y65).
Все.
Ну, или просто вырубить все на ночь, если такая возможность есть. У аплинка arp-кэш протухнет и все заработает штатно. Главное потом не включать 2900, а то она опять себя ему пропишет.

[lost_infidel]

Хотя, если ты в acl на входе трафик в адрес y67 уже видишь, то это все не твой случай. Ищи в другом месте :(