Cloud Native应用交付
  • 首页
  • 关于本站
  • 个人介绍
  • Downloads
  • Repo
    • Github
    • Container
  • F5
    • F5 Python SDK
    • F5-container
    • F5-LBaaS
  • 社交
    • 联系我
    • 微信/微博
    • 公众号
    • 打赏赞助
行至水穷处 坐看云起时
☁️We are in new App Mesh era: imesh.club ☁️
  1. 首页
  2. 协议原理
  3. 正文

RIP更新的规则[加工自深度博客]

2006年11月04日 4281点热度 0人点赞 0条评论

 
接收更新时,接收接口做如下检查:
如果更新是和本接口在同一主类网络下,则用本接口的MASK作为掩码,正因为如此,RIP需要是一致的掩码,否则就套错了(如果收到的是/32的主机路由更新,则接受它).
如果更新和本接口不在同一主类下,则检查路由表是否存在这个主类下的子网:
   存在,则忽略该更新.
   不存在则用主类的掩码(这里需要注意下:正常情况下更新如果不是和接收接口一个主类,则发送过来的更新就应该是个汇总的主类路由,而若两个路由器之间用的是无编号接口并包含子网信息的话,接收路由器将使用/32的主机掩码匹配这个更新).


发送更新,发送接口做如下检查:
更新是否和自己是同一主类,是的话,检查该路由的掩码是否和发送接口的掩码一致:
   一致则发送出去
  不一致,如果更新是/32的主机路由则发送更新,否则丢弃更新.
更新如果和发送接口不在同一主类,则自动汇总为主类网络发送出去.


Rtr A在发送更新包的时候,因为172.16.1.33/28与发送接口172.16.3.1/24同在一个主网络下,但是子网掩码不同,所以接口172.16.3.1/24不会向外通告172.16.1.33/28这一条路由。


Rtr A在发送更新包的时候,因为173.16.1.33/28与发送接口172.16.3.1/24不在同一个主网络下,所以接口172.16.3.1/24会通告一条173.16.0.0/16的路由。


Rtr A在发送更新包的时候,因为173.16.1.33/28与发送接口172.16.3.1/24不在同一个主网络下,所以接口172.16.3.1/24会通告一条173.16.0.0/16的路由,但Rtr B路由器在收到更新包的时候,检查自己的路由表有一条173.16.1.1/28的路由,所以Rtr B不会接收173.16.0.0/16这一条路由。


从上面可以看出,不连续子网下,R1先131.108.5.0/24汇总成131.108.0.0/16发送出去,接收的路由器因为接收接口和该路由条目不是一个主类,所以查看路由器是否存在该更新的子网,由于存在,所以忽略更新,因而导致了不连续子网在RIP下无法正常更新.

解决的方法:
把路由器配置第二个IP地址,使其成为一个连继的子网。
在两边使用默认路
原文http://www.norvel.com.cn/blog/user1/cn20004/archives/2006/94.html
 
更多CISCO-CASE
http://www.cisco.com/en/US/tech/tk364/technologies_tech_note09186a0080093fd8.shtml#nd

Why Don't RIPv1 and IGRP Support Variable-Length Subnet Mask?

http://www.cisco.com/en/US/tech/tk364/technologies_tech_note09186a0080093f1e.shtml
Don't RIPv1 and IGRP Support Variable-Length Subnet Mask?

本作品采用 知识共享署名 4.0 国际许可协议 进行许可
标签: 有类路由 RIP
最后更新:2006年11月04日

纳米

http://linjing.io

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

文章评论

取消回复

纳米

http://linjing.io

☁️迈向Cloud Native ADC ☁️

认证获得:
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
  • 点击查看本博技术要素列表
  • 分类目录
    • Avi Networks (3)
    • Cisco ACI (1)
    • CISCO资源 (21)
    • F5 with ELK (8)
    • F5-Tech tips (38)
    • F5技术 (203)
    • Juniper (4)
    • Linux (7)
    • Nginx (18)
    • SDN (4)
    • ServiceMesh (19)
    • WEB编程 (8)
    • WINDOWS相关 (7)
    • 业界文章 (18)
    • 交换机技术 (20)
    • 化云为雨/Openstack (35)
    • 协议原理 (52)
    • 容器/k8s (64)
    • 我的工作 (19)
    • 我的生活 (70)
    • 网站技术 (19)
    • 路由器技术 (80)
    • 项目案例 (28)
    文章归档
    标签聚合
    F5 k8s openstack nginx istio DNS envoy gtm docker network flannel api irule bigip neutron cc kubernetes ELK vxlan BGP dhcp VPN IPSec lbaas ingress ingress controller nginx plus sidecar IPSec VPN NAT sql
    最新 热点 随机
    最新 热点 随机
    Say hello for 2021 二进制flannel部署,非cni网络模式下与k8s CIS结合方案 又是一年国庆 Service Account Token Volume Projection Istio ingressgateway 静态TLS证书加载与SDS发现方式配置区别 Istio里Gateway的port定义与实际ingressgateway的listener端口关系及规则 Helm 3 部署NGINX Ingress Controller 应用交付老兵眼中的Envoy, 云原生时代下的思考 Istio sidecar iptables以及流量控制分析 Istio 熔断策略及envoy配置
    Say hello for 2021
    有意思,后端维护设备时可以考虑用用 [原]GTM配置关键点及排错总结 博客Docker化实践 Docker学习备忘1 [原创]DHCP原理及试验 51CTO独家调查显示:Web安全现状不容乐观 IBR(Intelligent Browser Rerferencing)总结 2010这一年 tcl实例详解 这张http irule的events顺序图好似有点问题?
    链接表
    • Jimmy Song‘s Blog
    • SDNap
    • SDNlab
    • SDN论坛
    • Service Mesh社区
    • 三斗室
    • 个人profile

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

    THEME KRATOS MADE BY VTROIS

    京ICP备14048088号-1

    京公网安备 11010502041506号

    [ Placeholder content for popup link ] WordPress Download Manager - Best Download Management Plugin