• 全部
  • 经验案例
  • 典型配置
  • 技术公告
  • FAQ
  • 漏洞说明
  • 全部
  • 全部
  • 大数据引擎
  • 知了引擎
产品线
搜索
取消
案例类型
发布者
是否解决
是否官方
时间
搜索引擎
匹配模式
高级搜索

H3C V7平台交换机普通代理ARP(proxy-arp)实现同网段终端跨越三层网络转发案例

2020-08-11 发表
  • 3关注
  • 7收藏 5168浏览
丁犁 八段
粉丝:83人 关注:1人

组网及说明


初始10.1.1.0/24网段终端 PC1、PC2、PC3、PC4 均连接SW1,SW1的 Vlan-interface 10 作为PC1、PC2、PC3、PC4的网关,如 图1 所示:


图1


后续业务迁移,将PC3、PC4迁移连接到 SW2。迁移后,需要 PC3、PC4 的IP地址保持不变,且PC1、PC2、PC3、PC4 之间业务需要互通,如 图2 所示:


图2



问题描述


按照 图2 的部署连接方式,SW1、SW2 均属于三层转发设备,使用12.1.1.0/30网段互联。跨越三层网络,要想实现同网段 PC1、PC2、PC3、PC4 之间业务互通,常见的思路是部署“叠加”Overlay网络。但考虑到“叠加”网络的部署。将在传统Underlay网络中,引用大量新技术特性,不便于用户网络的维护管理。因此使用传统的Underlay网络技术,实现业务需求。


在传统 Underlay 网络中,要想实现业务需求,可采用“普通代理ARP+静态路由”的方式部署实现,如 图3 所示:


图3


图3 关键配置为:

1、SW2上,同样创建Vlan-interface 10 ,其IP地址与SW1的Vlan-interface 10的地址一致(均为10.1.1.254/24);

2、SW1的Vlan-interface 10作为PC1、PC2的网关使能普通代理ARP(proxy-arp enable)功能;

3、SW2的Vlan-interface 10作为PC3、PC4的网关使能普通代理ARP(proxy-arp enable)功能;

4、SW1上,配置去往PC3、PC4的32位主机静态路由;

5、SW2上,配置去往PC1、PC2的25位网段静态路由(SW1侧除PC1、PC2以外实际还存在同网段的其他主机,为减少SW2上部署静态路由的数量,因此使用25位网段静态路由)。


根据上述图3 方式部署后,已 PC1 访问 PC3 为例,我们来观察报文在网络中的转发过程,进而对“普通代理ARP+静态路由”的方式有初步了解:

第一步:初始PC1 没有 PC3 的ARP信息,由于PC1、PC3 IP地址属于同网段,因此 PC1 向网络发出ARP请求报文。

             当SW1收到该ARP请求后,由于Vlan-interface 10 使能普通代理ARP功能,因此SW1“替代”PC3回应ARP。

             MAC = 0000-1010-1111为SW1 Vlan-interface 10的MAC地址。

             此时SW1能够学习到PC1 的ARP表项,且SW1产生去往PC1的FIB转发表项。

             如 图4 所示:


图4

第二步:PC1 获取到SW1代理回应的ARP报文后,将去往PC3 的目的MAC封装为0000-1010-1111,发送相关业务报文(这里用ICMP报文说明)。

             SW1 收到PC1 发往 PC3 的业务报文(ICMP报文),查找本地FIB表项,确认转发出接口;

             SW1 有部署去往10.1.1.3的静态主机路由,因此FIB表项中存在相应转发表项,出接口为G1/0/12,去往SW2;

             ICMP报文经过SW1三层转发后,重新封装二层源目MAC地址;

             SW1 GE1/0/12 MAC = 0000-1212-1111 ; SW2 GE1/0/12 MAC = 0000-1212-2222。

             如 图5 所示:


图5

第三步:SW2收到业务报文(ICMP报文)后,查找本地FIB表项,确认转发出接口;

             若SW2本地还没有PC3 的ARP信息时,查找本地FIB表项,ICMP报文目的IP = 10.1.1.3 根据最长掩码匹配原则,匹配10.1.1.0/24表项;

             此时SW2通过10.1.1.0/24表项对应的出接口Vlan-interface 10 发送ARP请求报文,希望获取PC3的ARP信息;

             PC3 收到 SW2 发送的ARP请求后进行回应。

             如 图6 所示:


图6

第四步:SW2 获取 PC3 的ARP信息后,学习到PC3的ARP信息,并且建立10.1.1.3/32的FIB转发表项; 

             SW2 重新封装ICMP报文二层源目MAC地址,并将ICMP报文发送给PC3。如 图7 所示:


图7

PC3 回应 PC1 的ICMP报文转发流程与上述步骤一、二、三、四类似,这里就不再重复介绍。


通过上述的介绍,证明“普通代理ARP+静态路由”的方式部署,可实现同网段终端跨越三层网络互访。


但是,随着PC1、PC2、PC3、PC4的业务在网络中传递,不定期出现 如PC1 与 PC3、PC3 与 PC4 之间无法访问,过一段实际又自行恢复的故障。



过程分析


针对采用“普通代理ARP+静态路由”的方式部署,出现的PC1与PC3、PC3 与 PC4 不定期无法互访的故障,实际可分为两类问题:

问题一:PC1与PC3 不定期无法互访故障,之后自动恢复;

问题二:PC3与PC4 不定期无法互访故障,之后自动恢复


针对问题一,进行分析:

分析1.1 :根据正常的报文交互原理,PC1 与 PC3之间的报文交付时,SW1、SW2正确的转发表项应为如 图8 所示。


图8

分析1.2:当PC1 无法与 PC3互访时,观察SW2 FIB表项,发现缺失 10.1.1.3/32 转发表项。

               出现这种情况的原因为:SW2上针对 10.1.1.3地址的ARP老化时间到期,而此时PC3本地针对网关10.1.1.254地址的ARP还未老化。

               因此SW2 没有接收到PC3发来的ARP请求报文,SW3最长可能存在20分钟ARP表项无10.1.1.3信息的情况,及FIB表项可能存在20分钟没有10.1.1.3/32 UH转发表项的情况。如 图9 所示: 


图9

分析1.3:此时若PC1 访问 PC3,当SW2收到目的IP = 10.1.1.3的流量时,SW2匹配本地FIB转发表项,根据最长匹配原则,匹配10.1.1.0/25表项。

               及SW2会将收到的流量再从G1/0/2扔给SW1。此时SW1收到相关流量,依照SW1本地10.1.1.3/32,SW1又一次扔给SW2。

              如此反复,直到报文TTL超期,因此造成 PC1 与 PC3 互访失败。如 图10 所示:


图10


针对问题二,进行分析:

分析2.1 :据报文交互原理,PC3 与 PC4 之间的报文交付时,PC3、PC4各自学习到对方到ARP信息。

                PC3、PC4之间业务报文目的MAC地址封装对端设备真实的MAC地址(同网段)。SW2其转发表项如 图11 所示。


图11

分析2.2:实际当使用Comware V7 平台交换机时,PC3 或 PC4 上学习到对端ARP信息,可能为SW2 Vlan-interface的MAC地址。理由如下:

               当SW2收到PC3请求PC4的ARP报文时,SW2 除了将ARP报文通过硬件芯片在同一个广播域内泛洪以外,SW2还会将该ARP请求报文复制(COPY)一份上送到SW2本地CPU上。

               由于SW2 已在Vlan-interface 10中,使能普通代理ARP功能,因此除了PC4回应ARP报文()外,交换机CPU还会回应ARP报文()。

               对于PC3 上ARP 10.1.1.4信息,对应的MAC可能为0000-4444-4444 或 0000-1010-2222。具体为多少,决定因素为,SW2最后收到的ARP回应报文。及PC 最后收到ARP回应,则ARP 10.1.1.4对应的MAC = 0000-1010-2222;PC 最后收到ARP回应,则ARP 10.1.1.4对应的MAC = 0000-4444-4444。

               如 图12 所示:


图12

分析2.3:若同时满足以下三个条件,则会出现PC3 与 PC4互访失败的问题。

  •                条件一:PC3 ARP学习到 10.1.1.4 对应的MAC = 0000-1010-2222;
  •                条件二:SW2 上对于10.1.1.4 ARP信息已经老化;
  •                条件三:PC4 上ARP表项未老化,及PC4 不主动发送ARP请求报文。

               当满足上述三个条件后,PC3 将访问 PC4的业务报文,目的MAC封装为0000-1010-2222。

               SW2收到这样的报文后,由于目的MAC为设备本地MAC,因此不会查找二层MAC地址表项进行转发,而是查找 FIB 表项转发。

               当SW2 查找 FIB表项时,由于SW2 上10.1.1.4 ARP信息已老化,因此SW2 FIB上不存在10.1.1.4/32的转发表。

               按照 FIB 表最长匹配原则,此时去往10.1.1.4的流量匹配10.1.1.0/25的转发表项。

               因此SW2 将去往10.1.1.4的业务报文,发给了SW1,产生故障。如 图13 所示:


图13


总结对故障一 和故障二的分析:

  • 故障均是由于交换机本地,出现终端的ARP表项信息老化后,没有及时收到终端发来的ARP请求,导致业务报文被“错误”的匹配到了FIB中另外的转发表项。
  • 出现异常时,若相关终端本地ARP表项老化后,其向网络中发出ARP请求,此时交换机会重新学习到终端到ARP表项,因此FIB表项中将生成新的32位主机转发表项,流量根据最长匹配原则,匹配到正确的转发表项后,业务恢复。



解决方法


了解了故障原因后,其解决方法即为,在SW2交换机上创建PC3、PC4的静态ARP。这样就可确保SW2上的FIB相关表项不老化消失。如 图14 所示:


图14

总结:

若希望通过代理ARP实现同网段终端跨越三层网络互访的部署,需要采用“普通代理ARP+静态路由+静态ARP”方式。


注意:

1、本案例适用于案例发布日期前,H3C所有Comware V7 平台交换机;

2、对于解决方法,当采用动态ARP表项老化探测功能(arp timer aging probe-interva/arp timer aging probe-count)时,无法解决交换机被管理员reset arp 动作导致终端ARP信息丢失的情况,因此不推荐使用。




该案例对您是否有帮助:

您的评价:1

若您有关于案例的建议,请反馈:

0 个评论

该案例暂时没有网友评论

编辑评论

举报

×

侵犯我的权益 >
对根叔知了社区有害的内容 >
辱骂、歧视、挑衅等(不友善)

侵犯我的权益

×

泄露了我的隐私 >
侵犯了我企业的权益 >
抄袭了我的内容 >
诽谤我 >
辱骂、歧视、挑衅等(不友善)
骚扰我

泄露了我的隐私

×

您好,当您发现根叔知了上有泄漏您隐私的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您认为哪些内容泄露了您的隐私?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)

侵犯了我企业的权益

×

您好,当您发现根叔知了上有关于您企业的造谣与诽谤、商业侵权等内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到 zhiliao@h3c.com 邮箱,我们会在审核后尽快给您答复。
  • 1. 您举报的内容是什么?(请在邮件中列出您举报的内容和链接地址)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
  • 3. 是哪家企业?(营业执照,单位登记证明等证件)
  • 4. 您与该企业的关系是?(您是企业法人或被授权人,需提供企业委托授权书)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

抄袭了我的内容

×

原文链接或出处

诽谤我

×

您好,当您发现根叔知了上有诽谤您的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您举报的内容以及侵犯了您什么权益?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

对根叔知了社区有害的内容

×

垃圾广告信息
色情、暴力、血腥等违反法律法规的内容
政治敏感
不规范转载 >
辱骂、歧视、挑衅等(不友善)
骚扰我
诱导投票

不规范转载

×

举报说明

提出建议

    +

亲~登录后才可以操作哦!

确定

亲~检测到您登陆的账号未在http://hclhub.h3c.com进行注册

注册后可访问此模块

跳转hclhub

你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作