Cloud Native应用交付

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

[实验扩展updated by 06/12/08]关于NAT中route-map.ACL顺序关系.

2006年07月4日 17179点热度 0人点赞 1条评论

今天作了BSCI第一章实验2之任务4之后,突然想到验证下在NAT过程中route-map acl路由器到底是先根据谁来找谁来决定最终如何转换的.
就利用任务4的结果了,在任务4里R1路由器配置是这样的:
任务的要求是源IP是10.1.1.0/24网络的目标到10.254.0.0/24网络的都转换成BBR池中的地址即192开头.
其他的都要转成POD池中地址即10开头的

ip nat pool bbr 192.168.1.1 192.168.1.254 prefix-length 24
ip nat pool pod 10.1.0.64 10.1.0.95 netmask 255.255.255.0
ip nat inside source route-map to-bbr pool bbr
ip nat inside source route-map to-pod pool pod

ip http server
ip classless
ip route 10.0.0.0 255.0.0.0 172.31.1.5
!        
!        
access-list 100 permit ip 10.1.1.0 0.0.0.255 10.254.0.0 0.0.0.255
access-list 101 permit ip 10.1.1.0 0.0.0.255 any
!        
route-map to-bbr permit 10
 match ip address 100
!        
route-map to-pod permit 10
 match ip address 101

先分析这个:
上面这个配置没有错误,路由器工作正常.
本来我的想法是路由器是先根据ACL找到ROUTE-MAP然后根据ROUTE-MAP所在的IP NAT INSIDE这样语句里指定的POOL池来转换的.
于是我改了下配置如下:
ip nat pool bbr 192.168.1.1 192.168.1.254 prefix-length 24
ip nat pool pod 10.1.0.64 10.1.0.95 netmask 255.255.255.0
ip nat inside source route-map to-bbr pool bbr
ip nat inside source route-map to-pod pool pod

ip http server
ip classless
ip route 10.0.0.0 255.0.0.0 172.31.1.5
!        
!  
access-list 101 permit ip 10.1.1.0 0.0.0.255 any     
access-list 100 permit ip 10.1.1.0 0.0.0.255 10.254.0.0 0.0.0.255

!        
route-map to-bbr permit 10
 match ip address 100
!        
route-map to-pod permit 10
 match ip address 101
注意上面的蓝色部分,我将ACL顺序调了下,如果按照我原先的理解(acl--route-map--pool)那么,此时不管是目的网络是什么,路由器都会按照101的acl找到route-map即to-pod,也就是都会转成pod池里的.但是实际实验结果却不是如同我想的,看来路由器不是先找ACL,难道是根据IP NAT INSIDE这个语句的排列顺序?可是不管我先写哪个,路由器最终都是认为ip nat inside source route-map to-bbr pool bbr这条语句在先.于是开始晕了,到群里和人讨论,网友☆诺メ言☆起初想法也和我一样,它也提出了ACL顺序问题,然后它提出no掉
ip nat inside source route-map to-bbr pool bbr这个语句,看路由器是否能正常转到POD地址池里,因为如果是先由ip nat inside语句来找route-map最后看是否匹配acl这个顺序的话,那么no 掉
ip nat inside source route-map to-bbr pool bbr 这个语句后,路由器应该转成POD里的地址池,但是实际测试结果不是这样,路由器给出了找不到BBR地址池,数据被丢弃这样的提示.看来路由器不是按照IP NAT INSIDE来先找的,现在能怀疑的就是ROUTE-MAP了,于是NO 掉route-map to-bbr permit 10 这个语句,此时数据来的时候,路由器只能根据route-map to-pod permit 10来匹配了,最终地址应该被转成pod池里的也就是10开头的,实际结果证明了我们的猜想.看来路由器是先根据ROUTE-MAP顺序来执行的,路由器先根据route-map找匹配的ACL,根据ACL检查数据是否符合要求,最后根据ROUTE-MAP所在的ip nat inside语句来转换.

一切看起来似乎已经解决了,但有一个疑问一直存在,我刚才改ip nat inside 不管先写哪个路由器最终的排的顺序为什么都不变呢,难道是根据字母顺序排列的?
ip nat inside source route-map to-bbr pool bbr
ip nat inside source route-map to-pod pool pod
看 前面单词都一样 不同的就是to-bbr 和to-pod这里了 b在p前面,于是我将to-bbr改成to-xbr ,路由器顺序果然也变了,于是同样更改route-map 顺序也变了,看来路由器真的是按照字母顺序排的,本任务第一个配置 之所以能始终正常而不管ACL的顺序是否符合正常的理论要求,就是因为ROUTE-MAP这个顺序始终没变.

最终修改的配置为:
ip nat pool pod 10.1.0.64 10.1.0.95 netmask 255.255.255.0
ip nat pool xbr 192.168.1.1 192.168.1.254 netmask 255.255.255.0
ip nat inside source route-map to-pod pool pod
ip nat inside source route-map to-xbr pool xbr

ip http server
ip classless
ip route 10.0.0.0 255.0.0.0 172.31.1.5
!        
!        
access-list 100 permit ip 10.1.1.0 0.0.0.255 any
access-list 101 permit ip 10.1.1.0 0.0.0.255 10.254.0.0 0.0.0.255

!        
route-map to-pod permit 10
 match ip address 100
!        
route-map to-xbr permit 10
 match ip address 101

在这个配置下,根据route-map 路由器会先调用acl100来检查数据是否符合,这个时候不管目的网络是什么都符合要求,路由器认为第一个route-map始终被匹配.所以始终会被转成POD池里的地址.下面是实际实验调试结果:
*Mar  1 03:34:01.423: NAT: s=10.1.1.3->10.1.0.67, d=10.254.0.5 [105]
r1-2514>
*Mar  1 03:34:03.415: NAT*: s=10.1.1.3->10.1.0.67, d=10.254.0.5 [106]
r1-2514>
*Mar  1 03:34:05.415: NAT*: s=10.1.1.3->10.1.0.67, d=10.254.0.5 [107]
r1-2514>
*Mar  1 03:34:07.419: NAT*: s=10.1.1.3->10.1.0.67, d=10.254.0.5 [108]
r1-2514>
*Mar  1 03:34:09.415: NAT*: s=10.1.1.3->10.1.0.67, d=10.254.0.5 [109]
------------------------
*Mar  1 03:34:24.139: NAT: s=10.1.1.3->10.1.0.67, d=10.1.0.2 [110]
*Mar  1 03:34:24.167: NAT*: s=10.1.0.2, d=10.1.0.67->10.1.1.3 [110]
*Mar  1 03:34:24.179: NAT*: s=10.1.1.3->10.1.0.67, d=10.1.0.2 [111]
*Mar  1 03:34:24.203: NAT*: s=10.1.0.2, d=10.1.0.67->10.1.1.3 [111]
*Mar  1 03:34:24.211: NAT*: s=10.1.1.3->10.1.0.67, d=10.1.0.2 [112]
*Mar  1 03:34:24.235: NAT*: s=10.1.0.2, d=10.1.0.67->10.1.1.3 [112]
*Mar  1 03:34:24.251: NAT*: s=10.1.1.3->10.1.0.67, d=10.1.0.2 [113]
*Mar  1 03:34:24.275: NAT*: s=10.1.0.2, d=10.1.0.67->10.1.1.3 [113]
*Mar  1 03:34:24.287: NAT*: s=10.1.1.3->10.1.0.67, d=10.1.0.2 [114]
*Mar  1 03:34:24.311: NAT*: s=10.1.0.2, d=10.1.0.67->10.1.1.3 [114]
可] ]>

相关文章

  • 暴风影音DNS事件分析
  • 配置组播(最少配置)
  • [转]RTR/SLA 在多ISP环境下下的应用--已经更新,切换后线路恢复时,已能自动恢复
  • 【原创】用CISCO VPN-Client4.01连接扩展验证-VPN-SERVER配置
  • 【原创】用CISCO VPN-Client4.01连接VPN-SERVER配置
本作品采用 知识共享署名-非商业性使用 4.0 国际许可协议 进行许可
标签: NAT BSCI 实验 试验 设备
最后更新:2006年07月4日

纳米

linjing.io

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

文章评论

  • 阿宝

    在看完你的文章后,我觉得有一点疑问,你在进行第二试验的时候,只是把ACL的输入顺序改了一下,并没有把ACL的NUMBER改啊!然后NAT出去的肯定是和第一次是一样的,ROUTER-MAP是根据访问控制列表的NUMBER来进行选择的,在你的第二次试验,ACL的NUMBER是和第一次是一样的,所以会产生和第一次一样的效果!
    access-list 101 permit ip 10.1.1.0 0.0.0.255 any
    access-list 100 permit ip 10.1.1.0 0.0.0.255 10.254.0.0 0.0.0.255
    而你最后的配置,就把ACL NUMBER改过来了,当ROUTERMAP运行时,是顺序查找,首先查找第一条附和的,如果第一条附和了那么就直接运行,你看一下你的ACL,ROUTERMAP第一句就是查找ACL NUMBER为100的控制列表,所以就会转成POD地址池.见意你把,第二次试验中的ACL NUMBER号对调一下,效果肯定会不一样的.我的MSN BAOLEE0203@HOTMAIL.COM,,我们可以讨论一下:)交个朋友的.
    access-list 100 permit ip 10.1.1.0 0.0.0.255 any
    access-list 101 permit ip 10.1.1.0 0.0.0.255 10.254.0.0 0.0.0.255

    2006年12月8日
    回复
  • razz evil exclaim smile redface biggrin eek confused idea lol mad twisted rolleyes wink cool arrow neutral cry mrgreen drooling persevering
    取消回复

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

    页面AI聊天助手

    纳米

    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
    • 我的工作
    • 我的生活
    • 网站技术
    • 路由器技术
    • 项目案例
    标签聚合
    openstack network api k8s docker gtm F5 istio envoy flannel bigip neutron irule nginx DNS
    最近评论
    汤姆 发布于 8 个月前(09月10日) 嗨,楼主,里面的json怎么下载啊,怎么收费啊?
    汤姆 发布于 8 个月前(09月09日) 大佬,kib的页面可以分享下吗?谢谢
    zhangsha 发布于 1 年前(05月12日) 资料发给我下,谢谢纳米同志!!!!lyx895@qq.com
    李成才 发布于 1 年前(01月02日) 麻烦了,谢谢大佬
    纳米 发布于 1 年前(01月02日) 你好。是的,因为以前下载系统插件在一次升级后将所有的下载生成信息全弄丢了。所以不少文件无法下载。DN...
    浏览次数
    • Downloads - 183,775 views
    • 联系我 - 118,966 views
    • 迄今为止最全最深入的BIGIP-DNS/GTM原理及培训资料 - 116,514 views
    • Github - 103,665 views
    • F5常见log日志解释 - 79,774 views
    • 从传统ADC迈向CLOUD NATIVE ADC - 下载 - 74,627 views
    • Sniffer Pro 4 70 530抓包软件 中文版+视频教程 - 74,320 views
    • 迄今为止最全最深入的BIGIP-DNS/GTM原理及培训资料 - 67,770 views
    • 关于本站 - 60,915 views
    • 这篇文档您是否感兴趣 - 55,495 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号