Cisco Nat load balancing + VRF. Как заставить работать ip nat inside destination на VRF?

Question

[Pavel_Krotov]

Все мы прекрасно знаем про возможность организации простой балансировки tcp сессий средствами NAT Destanation на роутере Cisco.
https://habr.com/ru/post/108978/

Но вот потребовалось "Cisco Nat load balancing" настроить на VRF, и оказывается, что нет параметра VRF в командах ip nat inside destination...
Как же заставить работать работать Cisco Nat load balancing + VRF вместе?

ip access-list extended CISCO-NAT-LB
permit tcp any host 5.5.5.5 eq 80 443 <-Внешние IP

ip nat pool CISCO-NAT-LB 10.1.1.1 10.1.1.2 netmask 255.255.255.0 type rotary <-Внутреннние IP серверов, на кого балансировать.
ip nat inside destination list CISCO-NAT-LB pool CISCO-NAT-LB

interface GigabitEthernet0/0.22
ip vrf forwarding VRF1
ip nat outside
ip address 172.1.1.2 255.255.255.0

interface GigabitEthernet0/0.23
ip vrf forwarding VRF1
ip nat inside
ip address 172.1.2.2 255.255.255.0

Answer 1

[Валентин]

На классическом ios вы должны сделать route leaking (статический маршрут в интерфейс в нужном vrf). NAT между vrf работает в ios-xe.
Но вашу задачу надо решать на отдельном балансере, это не работа маршрутизатора.

Comments

[Pavel_Krotov]

Вот попробовал в на CSR 1000v XE 16.9.01.
В Cisco Feature Navigator есть NAT - VRF-aware для данной версии, но для ISR4000, а не CSR..
Наверное, попробую и на железе, но надежды мало.

Трафик проходит по VFR интерфейсу, вижу срабатывает NAT, но после Ната трафик попадает на реальный роутер (Global) а не с VFR контекст (Видно по тому, что не работает, пока в Global не добавишь маршрут "ip route 10.1.1.0 255.255.255.0 GigabitEthernet0/0.23 172.1.2.3).
Итак, NAT сработал, пакет с измененным IP назначения выходит с правильного интерфейса GigabitEthernet0/0.23 и приходит на сервер. Все как бы хорошо.
Сервер отвечает, ответный пакет проходит через Inside/Outside VRF1, и выходит с Outside без NAT преобразования!!! (от 10.1.1.1, а не 5.5.5.5).
Близко, чуть чуть не хватает..
Как бы на это повлиять?

Понимаю, что есть более функциональные средства для LB, но Cisco NAT LB прекрасно справляется с поставленной задачей и сохраняет Source IP клиентов, а серверное ПО на это рассчитано. И протокол не HTTP (80,443), а TCP(5432) куда не вставишь "X-forwarder-for"
Спасибо за участие, в любом случае.

[Валентин]

Pavel_Krotov, Pavel_Krotov, явно обратный маршрут укажите через интерфейс outside

Answer 2

[iddqda]

уверен что не работает?
тут нужна поддержка VRF-Aware NAT т.е. несколько таблиц трансляций
циска знает что если пакет прилетел в интерфейс в VRF1 то и маршрутизировать и натить будет по соответствующим таблицам. Ничего в конфиг для этого отдельно прописывать не нужно.

И это старая фича. уже минимум лет 8 в IOS-ах такое реализовано

что за железяка?

Comments

[Pavel_Krotov]

Целевая железка Cisco 4331 IOS XE Software, Version 16.07.03,
Но пока я тестирую данный функционал в EVE-NG на CSR 1000V IOS XE 16.06.05.
И вижу что трафик проходит по VFR интерфейсу, вижу срабатывает NAT, но после Ната трафик выходит с реального роутера (Global) а не с VFR контекста (Если в Global добавить маршрут "ip route 10.1.1.0 255.255.255.0 GigabitEthernet0/0.23 172.1.2.3). А если на Global контексте нет маршрута к серверам 10.1.1.1 10.1.1.2 (а его там и не надо бы, поскольку интерфейс к серверам в vrf1), то трафик не отправляется.

Так же пробовал на эмуляции vIOS v15.5.3M, там вообще данный нат на VRF не срабатывает.

[iddqda]

ну что могу сказать
такого параметра нет и в последнем ios-xe 16.9.4 тоже
а работает ли оно в железе проверять не буду.
И я бы все же эту задачу поручил nginx-у

[Pavel_Krotov]

Вот попробовал в на CSR 1000v 16.9.01.
В Cisco Feature Navigator есть NAT - VRF-aware для данной версии, но для ISR4000, а не CSR..
Наверное, попробую и на железе, но надежды мало.

Трафик проходит по VFR интерфейсу, вижу срабатывает NAT, но после Ната трафик попадает на реальный роутер (Global) а не с VFR контекст (Видно по тому, что не работает, пока в Global не добавишь маршрут "ip route 10.1.1.0 255.255.255.0 GigabitEthernet0/0.23 172.1.2.3).
Итак, NAT сработал, пакет с измененным IP назначения выходит с правильного интерфейса GigabitEthernet0/0.23 и приходит на сервер. Все как бы хорошо.
Сервер отвечает, ответный пакет проходит через Inside/Outside VRF1, и выходит с Outside без NAT преобразования!!! (от 10.1.1.1, а не 5.5.5.5).
Близко, чуть чуть не хватает..
Как бы на это повлиять?

Понимаю, что есть более функциональные средства для LB, но Cisco NAT LB прекрасно справляется с поставленной задачей и сохраняет Source IP клиентов, а серверное ПО на это рассчитано. И протокол не HTTP (80,443), а TCP(5432) куда не вставишь "X-forwarder-for"
Спасибо за участие, в любом случае.

[iddqda]

Pavel_Krotov, Допускаю, что этот LB никому не уперся и конкретно этот извращенный вариант NAT-а просто не стали реализовывать.
Балансировать TCP умеет тот-же nginx, ha-proxy или даже iptables