(继续上一篇的5、结果验证)
5.5、不同网段,不同Leaf下服务器Ping
(抓包端口:
- Leaf1网络侧GE1/0/0和业务侧GE1/0/1
- Leaf2网络侧GE1/0/0和业务侧GE1/0/1)

1、分析
10.10.10.10和172.16.1.20是不同网段,处于不同Leaf下。
由于ENSP下,服务器都类似静默主机,不首先发起通信,所以存在arp过程。
谁首先发起Ping的场景不同。
假定10.10.10.10 ping 172.16.1.20,有以下操作:
1)arp1和arp1reply
首先,10.10.10.10 ping 172.16.1.20,由于10.10.10.10不知道自己网关10.10.10.1的mac(假定为mac1)地址,10.10.10.10先arp(假设为arp1),获得10.10.10.1的mac1。
10.10.10.1会记录10.10.10.10arp信息(检查命令:dis arp)。
2)icmp1,timeout
10.10.10.10对自己的网关mac地址解析完成后,发出第一个Ping包(简称icmp1)。第一个Ping包会超时。
3)arp2
Leaf1收到后,查询vpn1的路由表,由于172.16.1.1配置为分布式网关,Leaf1上的172.16.1.1需要负责路由这个Ping包,但此时172.16.1.1并不知道172.16.1.20在哪里,所以172.16.1.1需要发送arp2,请求获得172.16.1.20的mac2。这个arp2会从本地对应bridge-domian端口发出去;也会发往vxlan peer,送到Leaf2,Leaf2继续从本地对应bridge-domain端口(属于vxlan vni对应的bridge-domain的端口)发出arp2,最终172.16.1.20收到arp2。
4)arp2reply
182.16.1.20发送的arp2reply,会单播回复给172.16.1.1,Leaf2的172.16.1.1会处理这个arp2reply,并记录172.16.1.20的arp信息(检查命令:dis arp)。
5)irb route
Leaf2的172.16.1.1收到arp2reply,会把172.16.1.20/mac2这个arp信息形成evpn type2 irb route,通过bgp evpn update,宣告给RR(携带mac2/172.16.1.20/L2VNI/L3VNI/router mac),RR再宣告给Leaf1。
6)host route
Leaf1收到这个update,会更新自己对应bridge-domain的mac表和对应vpn的路由表(产生172.16.1.20的主机路由)。
7)icmp2
10.10.10.10发出第二个Ping包(icmp2),Leaf1收到去往172.16.1.20的icmp2后,查看vpn路由表的172.16.1.20的host route,会进行L3VNI vxlan封装,送Leaf2处理。Leaf2 NVE端口接受这个vxlan包,进行vxlan解封装,Leaf2查找本地路由表,决定从172.16.1.1送出icmp2,再依赖arp表,完成封装,最终从172.16.1.1的端口送出,到达172.16.1.20。
172.16.1.20发icmp2 reply,到达Leaf2后,查看vpn路由表10.10.10.0/24,下一跳为vxlan 20.20.20.20(这条路由是通过bgp evpn type 5 prefix route学习到的),进行L3VNI vxlan封装,送到Leaf1处理。Leaf1 NVE端口接受这个vxlan包,进行vxlan解封装,Leaf1查看vpn路由,决定从10.10.10.1送出icmp2 reply,再依赖arp表,完成封装,最终从10.10.10.1的端口送出,到达10.10.10.10。至此,完成了icmp2 request/reply的过程。
整个过程数据流如下图所示:

2、测试
1)ping前检查
ping之前,检查各表项相关信息都为空
10.10.10.10,arp -a,没有10.10.10.1的arp信息。

172.16.1.20,类似,没有172.16.1.1的arp信息。
Leaf1 mac/arp没有10.10.10.10/172.16.1.20相关信息:
[Leaf1]dis arp
ARP Entry Types: D - Dynamic, S - Static, I - Interface, O - OpenFlow, RD - Redirect
EXP: Expire-time VLAN:VLAN or Bridge Domain
IP ADDRESS MAC ADDRESS EXP(M) TYPE/VLAN INTERFACE VPN-INSTANCE
----------------------------------------------------------------------------------------
192.168.12.2 387d-c801-0100 I GE1/0/0
192.168.12.1 387d-c803-0101 19 D GE1/0/0
172.16.1.1 0001-0001-0001 I Vbdif100 vpn1
10.10.10.1 707b-e8da-5876 I Vbdif200 vpn1
----------------------------------------------------------------------------------------
Total:4 Dynamic:1 Static:0 Interface:3 OpenFlow:0
Redirect:0
[Leaf1]dis mac
Flags: * - Backup
BD : bridge-domain Age : dynamic MAC learned time in seconds
-------------------------------------------------------------------------------
MAC Address VLAN/VSI/BD Learned-From Type Age
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Total items: 0
[Leaf1]dis ip routin
[Leaf1]dis ip routing-table vpn
[Leaf1]dis ip routing-table vpn-instance vp
[Leaf1]dis ip routing-table vpn-instance vpn1
Proto: Protocol Pre: Preference
Route Flags: R - relay, D - download to fib, T - to vpn-instance, B - black hole route
------------------------------------------------------------------------------
Routing Table : vpn1
Destinations : 9 Routes : 9
Destination/Mask Proto Pre Cost Flags NextHop Interface
10.10.10.0/24 Direct 0 0 D 10.10.10.1 Vbdif200
10.10.10.1/32 Direct 0 0 D 127.0.0.1 Vbdif200
10.10.10.255/32 Direct 0 0 D 127.0.0.1 Vbdif200
172.16.1.0/24 Direct 0 0 D 172.16.1.1 Vbdif100
172.16.1.1/32 Direct 0 0

本文详细分析了在不同网段、不同Leaf下的服务器间通过 Ping 命令通信的过程。首先,10.10.10.10 发起 ARP 请求获取网关 mac 地址,然后发送 ICMP 请求,由于目标不在本地网段,Leaf1 发送 ARP 请求到 Leaf2,经过 VXLAN 封装,Leaf2 接收 ARP 请求并回应,最后建立路由并成功通信。在过程中,发现由于未配置 ARP 收集导致通信失败,通过调整配置解决问题。通过抓包分析,展示了整个通信过程中涉及的 ARP、IRB 路由、ICMP 请求/回复等关键步骤。
最低0.47元/天 解锁文章
2689





