Cloud Native应用交付

  • 首页
  • 关于本站
  • 个人介绍
  • Downloads
  • Repo
    • Github
    • Container
  • F5
    • F5 Python SDK
    • F5-container
    • F5-LBaaS
  • 社交
    • 联系我
    • 微信/微博
    • 公众号
    • 打赏赞助
行至水穷处 坐看云起时
Cloud Native Application Services: cnadn.net
  1. 首页
  2. 路由器技术
  3. 正文

NAT Support for Multiple Pools Using Route Maps

2007年05月22日 9425点热度 0人点赞 0条评论

Contents

Introduction
Prerequisites
      Requirements
      Components Used
      Conventions
Background Information
Access List Approach
      Host 1 to Host 2
      Host 1 to Host 3
Route Map Approach
      Host 1 to Host 2
      Host 1 to Host 3
Related Information


Introduction

This document explains how the use of access lists versus route maps changes the functionality of Network Address Translation (NAT). For more information on NAT, see Cisco IOS NAT.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

The information in this document is based on these software and hardware versions:

  • Cisco 2500 Series Routers.

  • Cisco IOS® Software Release 12.3(3).

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Background Information

NAT only uses access lists and route maps when it needs to create a translation entry. If a translation entry already exists that matches the traffic then the translation entry will be used; any access lists or route maps will not be consulted. The difference between using an access list or route map is the type of translation entry that will be created.

Route Maps

When NAT uses a route map to decide to create a translation entry, it will always create a "fully extended" translation entry. This translation entry will contain both the inside and outside (local and global) address entries and any TCP or UDP port information. Refer to NAT: Local and Global Definitions for more information on inside and outside (local and global) addresses.

Access Lists (no overload)

When NAT uses an access list to decide to create a translation entry, it will create a "simple" translation entry. This "simple" entry will only contain local and global IP address entries for just the inside or outside depending on whether the ip nat inside or ip nat outside command is configured. Also, it will not include any TCP or UDP port information.

Access Lists (with overload)

When NAT uses an access list, and overload has also been specified, NAT will create a "fully extended" translation entry. (Refer to Note1 ). The operation is similar to the route-map case except that route-map has some additional features. Refer to Note 2 for more details. You can see an example of a simple NAT translation entry and a fully extended NAT translation entry by selecting one of the links below:

  • Simple NAT translation entry

  • Fully extended NAT translation entry

Below is an example network diagram we will use to illustrate the difference between using a route map and an access list with NAT.

nat_routemap1.gif

In the example network diagram above, it is required that hosts on 10.1.1.0 be translated to the following:

  • 131.108.2.0 when going to 131.108.1.0

  • 131.118.2.0 when going to 131.118.1.0

Access List Approach

With an access list approach, you would do the following to translate the hosts on 10.1.1.0:

1
2
3
ip nat pool pool108 131.108.2.1 131.108.2.254 prefix-length 24<em><font color="#0000ff">!--- Defines a pool of global addresses to be allocated as needed.</font></em>      ip nat pool pool118 131.118.2.1 131.118.2.254 prefix-length 24     ip nat inside source list 108 pool pool108     <em><font color="#0000ff">!--- Establishes dynamic source translation, specifying the      !--- access list defined below.</font></em>      ip nat inside source list 118 pool pool118     interface ethernet0       ip address 10.1.1.1 255.255.255.0       ip nat inside       <em><font color="#0000ff">!--- Marks the interface as connected to the inside.</font></em>      interface ethernet1       ip address 10.1.2.1 255.255.255.0       ip nat outside       <em><font color="#0000ff">!--- Marks the interface
as connected to the outsid
e.</font></em>     access-list 108 permit ip 10.1.1.0 0.0.0.255 131.108.1.0 0.0.0.255     <em><font color="#0000ff">!--- Defines the access-list mentioning those addresses      !--- that are to be translated.</font></em>     access-list 118 permit ip 10.1.1.0 0.0.0.255 131.118.1.0 0.0.0.255

Refer to IP Addressing and Services Commands for more information on these commands.

Host 1 to Host 2

Here is what happens when Host 1 Telnets to Host 2.

1
Packet on (Network 1) s:10.1.1.2(1024)     d:131.108.1.2(23)     Packet on (Network 2) s:131.108.2.1(1024)  d:131.108.1.2(23)   (after NAT)

Because an access list was used by NAT to match this traffic a simple translation entry is created, which only includes inside translation information and no protocol or port information:

1
inside                         outside         local        global          global         local        10.1.1.2     131.108.2.1       ----           ----

Return packet: Host 2 to Host 1:

1
Packet on (Network 2)  s:131.108.1.2(23)  d:131.108.2.1(1024)     Packet on (Network 1)  s:131.108.1.2(23)  d:10.1.1.2(1024)      (after NAT)

Host 1 to Host 3

With the above simple translation in place, here is what happens when Host 1 also Telnets to Host 3:

1
Packet on (Network 1)  s:10.1.1.2(1025)     d:131.118.1.2(23)     Packet on (Network 2)  s:131.108.2.1(1025)  d:131.118.1.2(23)   (after NAT)

We can see that there is a problem. Packets going from 10.1.1.0 hosts to 131.118.1.0 hosts should get translated into 131.118.2.0, not 131.108.2.0. The reason that this happens is because there is already a NAT translation entry for 10.1.1.2 <--> 131.108.2.1 which also matches the traffic between Host 1 and Host 3. Therefore, this translation entry will be used and access lists 108 and 118 are not checked.

While the simple translation entry is in place in the NAT translation table, it can be used by any outside user on any outside host to send a packet to Host 1 as long as the outside user uses the inside global address (131.108.2.1) for Host 1. Normally a static NAT translation would be needed to allow this.

Route Map Approach

The correct way to configure the example in this document is to use route maps. With a route map approach, you would do the following to translate the hosts on 10.1.1.0:

1
ip nat pool pool-108 131.108.2.1 131.108.2.254 prefix-length 24     ip nat pool pool-118 131.118.2.1 131.118.2.254 prefix-length 24     ip nat inside source route-map MAP-108 pool pool-108     <em><font color="#0000ff">!--- Establishes dynamic source translation, specifying      !--- the route-map MAP-108 which is defined below. </font></em>     ip nat inside source route-map MAP-118 pool pool-118<em><font color="#0000ff">     !--- Establishes dynamic source translation, specifying the route-map MAP-118.     !--- Here, the route-maps are consulted instead of      !--- access-lists (as in the previous case).</font></em>     interface ethernet0       ip address 10.1.1.1 255.255.255.0       ip nat inside     interface ethernet1       ip address 10.1.2.1 255.255.255.0       ip nat outside     access-list 108 permit ip 10.1.1.0 0.0.0.255 131.108.1.0 0.0.0.255     access-list 118 permit ip 10.1.1.0 0.0.0.255 131.118.1.0 0.0.0.255     route-map MAP-108 permit 10     <em><font color="#0000ff">!--- Defines the Route-map MAP-108.</font></em>     match ip address 108     <em><font color="#0000ff">!--- Specifies the criteria for translation. Here, the IP      !--- address mentioned in the access-list 108 is translated.     !--- The translation is defined.</font></em>         in the ip nat inside source route-map MAP-108 pool pool-108 command     route-map MAP-118 permit 10     <em><font color="#0000ff">!--- Defines the Route-map MAP-108.</font></em>     match ip address 118     <em><font color="#0000ff">!--- The IP address mentioned in the access-list 118 is translated.      !--- The translation is defined in the      !--- <strong>ip nat inside source route-map MAP-118 pool pool-118</strong> command.</font></em>

Refer to IP Addressing and Services Commands for more information on these commands.

Host 1 to Host 2

Here is what happens when Host 1 Telnets to Host 2:

1
Packet on (Network 1) s:10.1.1.2(1024)     d:131.108.1.2(23)     Packet on (Network 2) s:131.108.2.1(1024)  d:131.108.1.2(23)   (after NAT)

In this case, because a route map was used by NAT to match the traffic to be translated, NAT will create a fully extended translation entry, which includes both inside and outside translation information:

1
inside                               outside         local            global             global             local     10.1.1.2:1024    131.108.2.1:1024   131.108.1.2:23     131.108.1.2:23

Return packet: Host 2 to Host 1:

1
Packet on (Network 2) s:131.108.1.2(23)  d:131.108.2.1(1024)     Packet on (Network 1) s:131.108.1.2(23)  d:10.1.1.2(1024)      (after NAT)

Host 1 to Host 3

Now when Host 1 sends a packet to Host 3 we get the following:

1
Packet on (Network 1) s:10.1.1.2(1025)     d:131.118.1.2(23)     Packet on (Network 2) s:131.118.2.1(1025)  d:131.118.1.2(23)   (after NAT)

The translation worked correctly because the packet on (N1) doesn't match the fully extended translation entry that was used for the Host 1 to Host 2 traffic. Because the existing translation doesn't match, NAT creates another translation entry for the Host 1 to Host 3 traffic.

Below are the fully extended translation entries on the NAT router:

1
inside                               outside         local            global             global             local     10.1.1.2:1024    131.108.2.1:1024   131.108.1.2:23     131.108.1.2:23     10.1.1.2:1025    131.118.2.1:1025   131.118.1.2:23     131.118.1.2:23

Because the NAT translation table has two full entries, it will correctly translate traffic going to the two different destinations from the same source.

Unlike the simple translation entry that was created via the access list, the fully extended translation entry created via the route map cannot be used by any other outside user to send a packet to Host 1. A static NAT translation would be needed to allow this.

Note 1

In the case of access-list with overload, the configuration is similar to the access-list without overload case. The exception is that you need to add the keyword overload to the command ip nat inside source list 108 pool pool108 and ip nat inside source list 118 pool pool118.

Note 2

The advantage of using route-maps is that under the match command you can have more options other than source IP address. For example, under the route-map, match interface or match ip next-hop can be specified. By using route-maps, you can specify the IP address as well as the interface or the next-hop address to which the packet is to be forwarded. Therefore, route-maps with NAT are used in a scenario where the subscriber is multi-homing to different ISPs.

相关文章

  • NAT-WITH ACL OR ROUTE-MAP
  • NAT - Ability to Use Route Maps with Static Translations
  • [原创]NAT中TCP负载均衡实验总结
  • 以前单位同事一次DHCP snooping排错经历
  • http://www.cisco.com/warp/public/707/gre_ipsec_ospf.html
本作品采用 知识共享署名-非商业性使用 4.0 国际许可协议 进行许可
标签: NAT
最后更新:2007年05月22日

纳米

linjing.io

打赏 点赞
< 上一篇
下一篇 >

文章评论

razz evil exclaim smile redface biggrin eek confused idea lol mad twisted rolleyes wink cool arrow neutral cry mrgreen drooling persevering
取消回复

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理。

页面AI聊天助手
文章目录
  • Contents
  • Introduction
  • Prerequisites
    • Requirements
    • Components Used
    • Conventions
  • Background Information
  • Access List Approach
    • Host 1 to Host 2
    • Host 1 to Host 3
  • Route Map Approach
    • Host 1 to Host 2
    • Host 1 to Host 3

纳米

linjing.io

☁️迈向Cloud Native ADC ☁️

认证获得:
TOGAF: ID 152743
Kubernetes: CKA #664
Microsoft: MCSE MCDBA
Cisco: CCNP
Juniper: JNCIS
F5:
F5 Certified Solution Expert, Security
F5 Certified Technology Specialist, LTM/GTM/APM/ASM
F5 Certified BIG-IP Administrator
  • 点击查看本博技术要素列表
  • 归档
    分类
    • AI
    • Automation
    • Avi Networks
    • Cisco ACI
    • CISCO资源
    • F5 with ELK
    • F5-Tech tips
    • F5技术
    • Juniper
    • Linux
    • NGINX
    • SDN
    • ServiceMesh
    • WEB编程
    • WINDOWS相关
    • 业界文章
    • 交换机技术
    • 化云为雨/Openstack
    • 协议原理
    • 容器/k8s
    • 我的工作
    • 我的生活
    • 网站技术
    • 路由器技术
    • 项目案例
    标签聚合
    istio api k8s nginx openstack envoy flannel neutron irule bigip DNS network gtm docker F5
    最近评论
    汤姆 发布于 9 个月前(09月10日) 嗨,楼主,里面的json怎么下载啊,怎么收费啊?
    汤姆 发布于 9 个月前(09月09日) 大佬,kib的页面可以分享下吗?谢谢
    zhangsha 发布于 1 年前(05月12日) 资料发给我下,谢谢纳米同志!!!!lyx895@qq.com
    李成才 发布于 1 年前(01月02日) 麻烦了,谢谢大佬
    纳米 发布于 1 年前(01月02日) 你好。是的,因为以前下载系统插件在一次升级后将所有的下载生成信息全弄丢了。所以不少文件无法下载。DN...
    浏览次数
    • Downloads - 184,603 views
    • 联系我 - 118,966 views
    • 迄今为止最全最深入的BIGIP-DNS/GTM原理及培训资料 - 117,961 views
    • Github - 104,600 views
    • F5常见log日志解释 - 80,103 views
    • 从传统ADC迈向CLOUD NATIVE ADC - 下载 - 76,057 views
    • Sniffer Pro 4 70 530抓包软件 中文版+视频教程 - 74,320 views
    • 迄今为止最全最深入的BIGIP-DNS/GTM原理及培训资料 - 67,770 views
    • 关于本站 - 61,446 views
    • 这篇文档您是否感兴趣 - 55,760 views
    链接表
    • F5SE创新
    • Jimmy Song‘s Blog
    • SDNlab
    • Service Mesh社区
    • 三斗室
    • 个人profile
    • 云原生社区

    COPYRIGHT © 2023 Cloud Native 应用交付. ALL RIGHTS RESERVED.

    Theme Kratos Made By Seaton Jiang

    京ICP备14048088号-1

    京公网安备 11010502041506号