nvi0 cisco что это
NAT Virtual Interface aka NVI, what is that?!
Not everyone knows that from IOS version 12.3(14)T, Cisco has introduced a new feature called NAT Virtual Interface; NVI removes the requirements to configure an interface as either NAT inside or NAT outside. An interface can be configured to use NAT or not use NAT.
How to use NVI? It’s easy! You must use the command ‘ip nat source …’ without specifying the inside/outside tag and enable the nat to the interfaces using the command ‘ip nat enable’.
For instance, if you use legacy statement:
with NVI feature the nat will be:
To better understand this feature, I will explain NVI using the same examples presented in the previous article ‘NAT and PAT: a complete explanation‘ (take no notice of the ip NAT inside/ouside in the images).
First of all, define which interfaces will take part in the IP translation; in these scenarios will be fastethernet 0/0 and fastethernet 0/1:
Then define the translation depending on the NAT/PAT used.
Example #1: Static NAT
How to translate the 172.16.0.5 IP address to the 10.16.0.5 ip address.
Define the static nat entry:
Example #2: Dynamic NAT
How to translate the 172.16.0.0/28 network in the 10.16.0.0/29 network.
Like legacy nat, you need define three things.
Define the nat pool used in the nat translation (this is the same as in legacy nat):
Define which network will be translated (this is the same as in legacy nat):
Define the dynamic NAT:
Example #3: Static PAT
How to expose two different services on Internet:
Define the static PAT:
Example #4: PAT – NAT Overload
How to share an Internet connection.
Define which network will be translated (this is the same as in legacy nat):
Define the NAT Overload:
Note: The behavior of the NAT Virtual Interface is the same of the legacy nat; for these reasons:
To check NVI statistics and translations use these commands (observe the ‘nvi’ tag):
Remember:
antiCisco blogs
блоги по технологиям и оборудованию cisco от инструкторов
NAT NVI или как настроить трансляцию адресов без направления
Наконец я собрался с мыслями и решился написать статью про NAT NVI. Надо сказать, что вообще сама по себе трансляция адресов на роутере многократно рассматривалась, в т.ч. в статье «По просьбам трудящихся: Dual ISP на маршрутизаторах cisco без BGP». Тем не менее, описанный в ней механизм inside source и outside source NAT имеет некоторые ограничения.
Задача 1.
В частности, рассмотрим топологию: 
Постановка задачи.
Требуется транслировать на R0:
Поскольку адрес интерфейса один, то естественно используется PAT.
Решение № 1.
Сами по себе трансляции пишутся для каждого случая довольно просто.
Router(config)# access-list 101 permit ip 10.0.2.0 0.0.0.255 10.0.1.0 0.0.0.255
Router(config)# ip nat inside source list 101 interface fa 0/0 overload
Router(config)# access-list 102 permit ip 10.0.3.0 0.0.0.255 10.0.2.0 0.0.0.255
Router(config)# ip nat inside source list 102 interface fa 0/1 overload
Теперь нам, требуется указать для каждого интерфейса, участвующего в трансляции, является он внутренним (inside) или внешним (outside) для трансляции. Вроде все просто но вот незадача: интерфейс fa 0/1 нужно будет сделать одновременно inside и outside. Что невозможно, поскольку каждый интерфейс может быть либо inside, либо outside.
Решить такую задачу с помощью классического NAT можно только с серьезными ухищрениями.
Первый способ решения состоит в применении технологии PBR (policy based routing). Идея состоит в следующем:
Теперь, собственно, давайте подойдем к тому варианту, из-за которого и писалась эта статья.
Технология Cisco NVI NAT (или ее еще часто называют ip nat enable) позволяет нам не заботиться о маркировании интерфейсов как inside или outside. Мы просто маркируем их, как включенные в NAT с помощью команды
Router(config-if)# ip nat enable
И пишем унифицированные правила. В частности для нашего случая, эти правила будут отличаться только отсутствием слова inside:
Router(config)# access-list 101 permit ip 10.0.2.0 0.0.0.255 10.0.1.0 0.0.0.255
Router(config)# access-list 102 permit ip 10.0.3.0 0.0.0.255 10.0.2.0 0.0.0.255
Router(config)# ip nat source list 101 interface fa 0/0 overload
Router(config)# ip nat source list 102 interface fa 0/1 overload
А роутер сам разбирается, при получении на интерфейс пакета, подвергать этот пакет прямой или обратной трансляции, и какое у этой трансляции направление.
Естественно, такая «автоматика» требует гораздо более внимательного задания «интересного» трафика для трансляции, поскольку если описать его слишком поверхностно, можно получить непредсказуемое число трансляций в обе стороны.
Тем не менее, описанная топология достаточно редко встречается в реальных сетях. Как правило, она требуется мелким провайдерам. И поэтому, сейчас я хотел бы описать решение более жизненной задачи.
Постановка задачи.
Часто бывает, что для некоторых запросов извне нам бы хотелось представить «запрашивающих» в качестве некоторого внутреннего адреса.
Рассмотрим топологию 
Условия задачи:
Поскольку количество адресов в интернете превышает любой наперед заданный пул, а сервер может быть очень посещаемый, то данное решение слабо нам подходит.
Решение.
Обратимся к Cisco NVI. Поскольку направление трансляции больше не задается на интерфейсах, мы можем сделать несколько прямых PAT-трансляций:
1. Трансляция для выхода в интернет наших хостов:
Router(config)# access-list 100 permit ip 192.168.0.0 0.0.0.255 any
Router(config)# ip nat source list 100 interface fa0/0 overload
2. Трансляция для проброса порта:
ip nat source static tcp 192.168.1.2 22 172.16.1.5 22 extendable
3. Трансляция адресов всевозможных запрашивающих хостов во внутренний адрес 192.168.0.201
Router(config)# access-list 101 permit tcp any host 172.16.1.5 eq 22
Router(config)# ip nat pool SERV_PAT 192.168.0.201 192.168.0.201 prefix-length 24
Router(config)# ip nat source list 101 pool SERV_PAT overload
Другими словами, мы совместили две динамических PAT-трансляции и одну статическую.
Конечно, данная статья не претендует на всевозможное раскрытие возможностей Cisco NVI NAT, тем не менее, она может быть полезна тем, кто часто использует NAT в своих топологиях и не хочет ограничивать себя возможностями классического NAT.
Двусторонний NAT (PAT) на Cisco IOS или NAT NVI
По просьбе коллеги (Fedia) я собрался с мыслями и решился написать статью про NAT NVI. Надо сказать, что вообще сама по себе трансляция адресов на роутере многократно рассматривалась, в т.ч. в статье «По просьбам трудящихся: Dual ISP на маршрутизаторах cisco без BGP». Тем не менее, описанный в ней механизм inside source и outside source NAT имеет некоторые ограничения.
Router(config)# access-list 102 permit ip 10.0.3.0 0.0.0.255 10.0.2.0 0.0.0.255
Router(config)# ip nat inside source list 102 interface fa 0/1 overload
Граничные условия. Здесь позволю себе сделать несколько оговорок.
Во-первых, хотел бы обратить внимание, что такая хитрость возможно далеко не всегда. Дело в том, что PBR срабатывает раньше, чем inside-to-outside NAT (см. статью Cisco: Порядок обработки пакетов «в сложных конфигурациях»). В случае с outside-to-inside NAT это не верно, т.е. сначала проверяются правила NAT.
Во-вторых, мы создаем излишнюю нагрузку на роутер, т.к. отправка пакетов через PBR всегда нагружает процессор.
Т.е. решение, хотя и не выходит за рамки классического NAT, стоит на весьма хилых подпорках.
Решение № 2.
Теперь, собственно, давайте подойдем к тому варианту, из-за которого и писалась эта статья.
Технология Cisco NVI NAT (или ее еще часто называют ip nat enable) позволяет нам не заботиться о маркировании интерфейсов как inside или outside. Мы просто маркируем их, как включенные в NAT с помощью команды
Router(config-if)# ip nat enable
И пишем унифицированные правила. В частности для нашего случая, эти правила будут отличаться только отсутствием слова inside:
Router(config)# access-list 101 permit ip 10.0.2.0 0.0.0.255 10.0.1.0 0.0.0.255
Router(config)# access-list 102 permit ip 10.0.3.0 0.0.0.255 10.0.2.0 0.0.0.255
Router(config)# ip nat source list 101 interface fa 0/0 overload
Router(config)# ip nat source list 102 interface fa 0/1 overload
А роутер сам разбирается, при получении на интерфейс пакета, подвергать этот пакет прямой или обратной трансляции, и какое у этой трансляции направление.
Естественно, такая «автоматика» требует гораздо более внимательного задания «интересного» трафика для трансляции, поскольку если описать его слишком поверхностно, можно получить непредсказуемое число трансляций в обе стороны.
Тем не менее, описанная топология достаточно редко встречается в реальных сетях. Как правило, она требуется мелким провайдерам. И поэтому, сейчас я хотел бы описать решение более жизненной задачи.
Конечно, данная статья не претендует на всевозможное раскрытие возможностей Cisco NVI NAT, тем не менее, она может быть полезна тем, кто часто использует NAT в своих топологиях и не хочет ограничивать себя возможностями классического NAT.
ciscolinux 😉
Cisco networking and linux tutorials
Cisco weird interfaces
NVI – NAT Virtual Interface
Not everyone knows that from IOS version 12.3(14)T, Cisco has introduced a new feature called NAT Virtual Interface; NVI removes the requirements to configure an interface as either NAT inside or NAT outside. An interface can be configured to use NAT or not use NAT.
How to use NVI? It’s easy! You must use the command ‘ip nat source …’ without specifying the inside/outside tag and enable the nat to the interfaces using the command ‘ip nat enable’.
For instance, if you use legacy statement:
with NVI feature the nat will be:
Define the NAT Overload:
To check NVI statistics and translations use these commands (observe the ‘nvi’ tag)
SVI – Switch Virtual Interface
Cisco offers different flavors of integrated switching modules for the modular Cisco 3900, 3800, 2900, 2800, 1900 and 1800 Series Integrated Services Routers. Cisco 4- and 8-Port Gigabit Ethernet Enhanced High-Speed WAN Interface Cards (EHWICs) are used with Cisco 1900 series ISR G2 routers.
The integrated switch ports for the fixed-configuration Integrated Services Routers and the switch ports on the HWICs/EHWICs do not natively support Layer 3 addresses or Layer 3 features. They must be assigned to a SVI and use a VLAN interface for Layer 3 features. SVI represents a logical Layer 3 interface on a switch. In addition to basic routing, SVI can be used to support additional features for the network that the SVI represents.
A switch virtual interface (SVI) is a VLAN of switch ports represented by one interface to a routing or bridging system. There is no physical interface for the VLAN and the SVI provides the Layer 3 processing for packets from all switch ports associated with the VLAN.
There is one-to-one mapping between a VLAN and SVI, thus only a single SVI can be mapped to a VLAN. By default, a SVI is created for the default VLAN (VLAN1) to permit remote switch administration. An SVI cannot be activated unless associated with a physical port.
SVIs are generally configured for a VLAN for the following reasons:
BVI – Bridged Virtual Interface
With wireless AP’s you are bridging the wireless traffic between your wireless vlans and the local lan subnets. The BVI interface also has to have an ip address on your “native” vlan subnet, whatever that may be. Since cisco ap’s only have layer 2 interfaces then the BVI is necessary.
If you assign an ip to a vlan interface, any traffic between the different subnets is no longer bridged, it is routed. You also can only bridge non ip traffic on cisco switches. (IPX, IPV6 on older platforms)
In a wireless network, bridge groups are configured on the wireless access points and bridges in order for the data traffic of a VLAN to be transmitted from wireless media to the wired side and vice versa.
In general, bridge groups create segmented switching domains. Traffic is confined to hosts within each bridge group, but not between the bridge groups. The switch forwards traffic only among the hosts that make up the bridge group, which restricts broadcast and multicast traffic (flooding) to only those hosts. Bridge groups relieve network congestion and provide additional network security when they segment traffic to certain areas of the network.
Refer to Bridging Overview for detailed information.
VRF – Virtual Routing and Forwarding
Virtual Routing and Forwarding (VRF) is a technology included in IP network routers that allows multiple instances of a routing table to exist in a router and work simultaneously. This increases functionality because it allows network paths to be segmented without the use of multiple devices. Because traffic is automatically segregated, VRF also increases network security and can eliminate the need for encryption and authentication. Internet Service Providers (ISPs) often take advantage of VRF in order to create separate Virtual Private Networks (VPNs) for customers. Therefore the technology is also referred to as VPN routing and forwarding.
VRF acts like a logical router, but while a logical router can include many routing tables, a VRF instance uses only a single routing table. In addition, VRF requires a forwarding table that designates the next hop for each data packet, a list of devices that can be called upon to forward the packet, and a set of rules and routing protocols that govern how the packet is forwarded. These tables prevent traffic from being forwarded outside a specific VRF path and also keep out traffic that must remain outside the VRF path.
SLIDER.WEB studio
СоцСсылки
NVI NAT на Cisco
Не так давно мне понадобилось реализовать достаточно востребованную многими заказчиками, но редко используюемую инженерами схему NAT, а именно, обеспечить доступ из внутренней локальной сети к ресурсу, который проброшен изнутри этой же сети наружу, через транслирующий внешний интерфейс. Другими словами: Доступ на внешний интерфейс из за NAT.
Я обычно пытаюсь всячески избегать подобных топологий(патологий), однако заказчик настаивал, так как выхода у него особо небыло.
Данная фича называется NAT Hairpin, но обычно ее называют NVI NAT. Отличие данного метода от обычного NAT заключается в том, что трансляция происходит между маркированными интерфейсами, согласно таблицы маршрутизации, и маршрутизатору абсолютно не интересно какой интерфейс inside, а какой outside.
Зачем это нужно:
Решить данную проблему можно используя PBR с ухищрениями, либо воспользоваться функционалом NVI.
Настрока NVI NAT несколько отличается, ввиду изменения логики работы.
Если при обычном NAT мы помечали интерфейсы как
то теперь, на всех внешних и внутренних интерфейсах, задействованных в трансляциях, необходимо сказать
Так как наши интерфейсы теперь ни inside ни outside, то и правила трансляций тоже поменяются, а именно:
Posted in Инфраструктура, Полезности on сен 13, 2017