【业务领域】以太Mac/IP/UDP/TCP报文格式简介

以太Mac/IP/UDP/TCP报文格式介绍

  • 以太mac格式:
    • VLAN
    • 两层VLAN/QinQ
    • arp、rarp
      • RARP 协议
      • cnp
      • LLDP
      • PAUSE
      • PFC PAUSE
      • IPv4报文格式:
        • ipv4 option
        • IPv6报文格式:
          • ipv6 option
          • UDP报文格式:
          • TCP报文格式
          • GRE
          • SCTP
          • ICMP
          • IGMP
          • STP/RSTP/MSTP
          • VxLAN
            • VxLAN是什么?
            • VXLAN与VLAN之间有何不同?
            • NVGRE
            • GENEVE
            • 1588

              以太mac格式:

              长度/类型域段:

              VLAN

              VLAN (Virtual Local Area Network)意为虚拟局域网,是在交换机实现过程中涉及到的概念,由802.1Q标准所定义。由于交换机是工作在链路层的网络设备,连接在同一台交换机的终端处于同一个三层网中,同时也处于同一个广播域。当交换机接入较多的终端时,任意一台终端发送广播报文时(例如:ARP请求),报文都会传遍整个网络。对于规模较大的组网场景,广播报文的泛滥对于网络通信将会造成较大的影响。

              VLAN技术为这一问题提供了解决方案,VLAN将同一网络划分为多个逻辑上的虚拟子网,并规定当收到广播报文时,仅仅在其所在VLAN中进行广播从而防止广播报文泛滥。VLAN技术在链路层的层次中实现了广播域的隔离。

              VLAN数据帧:

              VID字段:唯一标识了一个VLAN,12bit长度的VID可以表示4096个不同的值,除去两个保留值,一个以太网最多可以划分为4094个VLAN。

              字段长度含义取值
              TPID2ByteTag Protocol Identifier(标签协议标识符),表示数据帧类型。表示帧类型,取值为0x8100时表示IEEE 802.1Q的VLAN数据帧。如果不支持802.1Q的设备收到这样的帧,会将其丢弃。 各设备厂商可以自定义该字段的值。当邻居设备将TPID值配置为非0x8100时, 为了能够识别这样的报文,实现互通,必须在本设备上修改TPID值,确保和邻居设备的TPID值配置一致。
              PRI3bitPriority,表示数据帧的802.1Q优先级。取值范围为0~7,值越大优先级越高。当网络阻塞时,设备优先发送优先级高的数据帧。
              CFI1bitCanonical Format Indicator(标准格式指示位),表示MAC地址在不同的传输介质中是否以标准格式进行封装,用于兼容以太网和令牌环网。CFI取值为0表示MAC地址以标准格式进行封装,为1表示以非标准格式封装。在以太网中,CFI的值为0。
              VID12bitVLAN ID,表示该数据帧所属VLAN的编号。VLAN ID取值范围是0~4095。由于0和4095为协议保留取值,所以VLAN ID的有效取值范围是1~4094。
              设备利用VLAN标签中的VID来识别数据帧所属的VLAN,广播帧只在同一VLAN内转发,这就将广播域限制在一个VLAN内。
              

              VLAN原理详解中讲述了VLAN的出现原因和使用方法:VLAN原理详解

              VLAN基础知识

              两层VLAN/QinQ

              QinQ(802.1Q in 802.1Q)技术是一项扩展VLAN空间的技术,通过在802.1Q标签报文的基础上再增加一层802.1Q的Tag来达到扩展VLAN空间的功能。

              随着以太网技术在网络中的大量部署,利用VLAN对用户进行隔离和标识受到很大限制。因为IEEE802.1Q中定义的VLAN Tag域只有12个比特,仅能表示4096个VLAN,无法满足城域以太网中标识大量用户的需求,于是QinQ技术应运而生。

              如下图所示用户报文在公网上传递时携带了两层Tag,内层是私网Tag,外层是公网Tag。

              QinQ封装报文是在无标签的以太网数据帧的源MAC地址字段后面加上两个VLAN标签构成.

              arp、rarp

              ARP 协议的全称是 Address Resolution Protocol(地址解析协议),它是一个通过用于实现从 IP 地址到 MAC 地址的映射,即询问目标 IP 对应的 MAC 地址 的一种协议。ARP 协议在 IPv4 中极其重要。

              注意:ARP 只用于 IPv4 协议中,IPv6 协议使用的是 Neighbor Discovery Protocol,译为邻居发现协议,它被纳入 ICMPv6 中。
              

              简而言之,ARP 就是一种解决地址问题的协议,它以 IP 地址为线索,定位下一个应该接收数据分包的主机 MAC 地址。如果目标主机不在同一个链路上,那么会查找下一跳路由器的 MAC 地址。

              域段含义

              前面 14 个字节构成标准以太网的首部,前两个字段 DST 和 SRC 分别表示 以太网的目的地址 和 以太网的源地址,以太网的目的地址如果是 ff:ff:ff:ff:ff:ff 全部为 1 表示广播地址,在同一广播域中的所有以太网接口可以接收这些帧。后面紧跟着的是 ARP 请求的长度/类型,ARP 请求 和 ARP 应答这个值为 0x0806。

              硬件类型表示硬件地址的类型,硬件地址常见的有 MAC 物理或者以太网地址,对于以太网来说,此值为 1。

              协议类型 指出映射的协议地址类型,对于 IPv4 地址,这个值是 0x0800。

              硬件大小和 协议大小 分别指出硬件地址和协议地址的字节数。对于以太网中使用 IPv4 的 ARP 请求或应答,它们的值分别是 6 和 4。

              Op 字段指出如果是 ARP 请求,Op = 1,ARP 应答 ,Op = 2,RARP 请求 Op = 3,RARP 应答,Op = 4。

              紧跟在 Op 之后的是 发送方硬件地址(MAC 地址),发送方的协议地址(IPv4 地址),目的硬件地址 和 目的协议地址。后面四个字段写入的是一些物理地址和协议地址。不一定全部有值。 对于ARP Request 而言,我们不知道目的MAC地址是什么,因此 Target’s Hardware Address 全部填充为0。

              ARP帧的交互:当主机接收到一个针对其协议地址的ARP Request时,它会回应ARP Reply. 该Reply消息内容为:对调sender 和 Target 地址字段,然后将Sender’s Hardware Address(即原来的Target’s Hardware Address )修改为本机的Hardware Address。另外OP字段有1变为2.

              RARP 协议

              Reverse Address Resolution Protocol 反向地址转换协议,用于获得已知 MAC 地址的 IP 地址。

              一般在主机刚接入网络时,通过本地 MAC 地址来发送 RARP 请求,如果局域网内有 RARP Server 且 Server 上存在关于此 MAC 地址的映射 IP,则会返回 RARP Reply 响应,此时主机就获取了 IP 地址。

              • 需要 RARP 服务器,一般用于无法使用 DHCP 或没有任何输入接口的小型嵌入式设备
              • 主机以广播的形式发送 RARP 请求包,声明自己的 MAC 地址,并请求分配一个 IP 地址
              • RARP 服务器收到 RARP 请求包后,检查 RARP 列表,查找该 MAC 地址对应的 IP 地址;

                若存在,则返回 RARP 响应包,成功分配 IP 地址;

                若不存在,则不做任何响应,分配 IP 地址失败;

                解释一下arp的含义

                cnp

                LLDP

                LLDP定义:

                LLDP(Link Layer Discovery Protocol)是IEEE 802.1ab中定义的链路层发现协议。LLDP是一种标准的二层发现方式,可以将本端设备的管理地址、设备标识、接口标识等信息组织起来,并发布给自己的邻居设备,邻居设备收到这些信息后将其以标准的管理信息库MIB(Management Information Base)的形式保存起来,以供网络管理系统查询及判断链路的通信状况。

                LLDP存在的目的:

                随着网络规模越来越大,网络设备种类繁多,并且各自的配置错综复杂,对网络管理能力的要求也越来越高。传统网络管理系统多数只能分析到三层网络拓扑结构,无法确定网络设备的详细拓扑信息、是否存在配置冲突等。

                因此需要有一个标准的二层信息交流协议。LLDP提供了一种标准的链路层发现方式。通过LLDP获取的设备二层信息能够快速获取相连设备的拓扑状态;显示出客户端、交换机、路由器、应用服务器以及网络服务器之间的路径;检测设备间的配置冲突、查询网络失败的原因。企业网用户可以通过使用网管系统,对支持运行LLDP协议的设备进行链路状态监控,在网络发生故障的时候快速进行故障定位。

                LLDP报文格式

                Destination MAC address: 目的MAC地址,为固定的组播MAC地址0x0180-C200-000E。

                Source MAC address: 源MAC地址,为端口MAC地址或设备桥MAC地址(如果有端口地址则使用端口MAC地址,否则使用设备桥MAC地址)

                Type: 报文类型,固定为0x88CC。

                Data: 数据,为LLDPDU

                FCS: 帧检验序列

                其中LLDPDU 就是封装在LLDP报文数据部分的数据单元。只不过在组成LLDPDU之前,设备会先将本地的相关信息封装成TLV,然后再将多个TLV组合成一个LLDPDU,封装在LLDP报文的数据部分进行传送。

                LLDP报文发送机制

                当使能LLDP功能时,设备会周期性地向邻居设备发送LLDP报文。如果设备的本地配置发生变化则立即发送LLDP报文,以将本地信息的变化情况尽快通知给邻居设备。为了防止本地信息的频繁变化而引起LLDP报文的大量发送,每发送一个LLDP报文后都需延迟一段时间后再继续发送下一个报文。

                LLDP报文接收机制

                当使能LLDP功能时,设备会对收到的LLDP报文及其携带的TLV进行有效性检查,通过检查后再将邻居信息保存到本地设备,并根据LLDPDU报文中TLV携带的TTL值设置邻居信息在本地设备的老化时间。如果接收到的LLDPDU中的TTL值等于零,将立刻老化掉该邻居信息。

                LLDP简介

                PAUSE

                Pause报文是IEEE802.3协议中描述的一种用于控制MAC数据流量的报文。

                当对端数据量过大,将无法及时处理数据时,会向数据上游MAC发送Puase报文,告诉上游MAC在一段时间内停止发送数据,停止时间记录在报文的PAUSE_TIMING字段。当上游MAC接受到对端的有效Puase报文时,会开始计时,并会停止发送数据,防止对端无法及时处理数据,导致对端FIFO溢出或者数据丢失。若计时结束,并且没有收到新的pause报文,将重新发送数据。若计时没有结束,且新收到的pause报文PAUSE_TIMING字段为全0,则表示可以重新发送数据,此时停止计时,重新开始发送数据。

                Pause报文由IEEE802.3协议规定,与标准以太帧格式相似:

                DA表示目的地址,地址数据固定为0x180c2000001;

                SA表示源地址 地址由发送方确定

                TYPE为报文类型字段,固定为0X8808

                OPCODE为操作码,固定为0X0001

                PAUSE_TIMING字段为上游MAC停止发送数据的时间,每单位为512bit传输时间,数值为16’d1024表示暂停时间为MAC传输1024*512bit数据所需要的时间

                PAD:为填充字段,所有值为0

                FCS: 为校验字段,通常为CRC校验值

                PFC PAUSE

                基于优先级的流量控制(PFC:Priority-based Flow Control)在IEEE:802.1Qbb标准文档中定义,对传统流控的暂停机制一种增强。

                与传统的流控机制相比,当出现拥塞时传统流控但会阻止一条链路上的所有流量。而PFC允许在一条以太网链路上创建8个虚拟通道,并为每条虚拟通道指定一个IEEE 802.1P优先等级(cos),允许单独暂停和重启其中任意一条虚拟通道,同时允许其它虚拟通道的流量无中断通过。

                这一方法使网络能够为单个虚拟链路创建无丢包类别的服务,使其能够与同一接口上的其它流量类型共存。其实PFC就是普通流控功能的一种增强。

                报文格式:

                Destination address:目的MAC地址,取值固定为01-80-c2-00-00-01。

                Source address:源MAC地址。

                Ethertype :以太网帧类型,取值为8808。

                Control opcode:控制码,取值为0101。

                Priority enable vector:反压使能向量。

                Time(0)~Time(7):其中E(n)和优先级队列n对应,表示优先级队列n是否需要反压。当E(n)=1时,表示优先级队列n需要反压,反压时间为Time(n);当E(n)=0时,则表示该优先级队列不需要反压。

                Pad:预留。传输时为0。

                CRC:循环冗余校验。

                IPv4报文格式:

                ipv4 option

                IPv6报文格式:

                ipv6 option

                UDP报文格式:

                TCP报文格式

                GRE

                GRE(Generic Routing Encapsulation),通用路由封装协议。顾名思义,这种隧道协议对链路两端实际所使用的网络协议没有要求,是一种很常用的隧道协议。

                有这样场景,如果我在原始IP报文(本机IP:8.8.8.8)前面再封装一层IP头+隧道头,目的地址就是节点A的地址x.x.x.x,这样,在网络中的各个设备就会根据这个x.x.x.x去路由查找,最终找到节点A,节点A对原始报文处理之后再扔出去,最终路由到8.8.8.8上面。这个就是隧道技术,也可以说是overlay技术,顾名思义就是把原始报文隐藏在里面,外面再封装一层,在网络中的路由器和交换机识别的都是外层封装的信息,就相当于戴了个面具,中间设备认识的是你这个面具,等到了隧道端点,解除隧道封装后,还原原始报文,面具摘掉了,露出庐山真面目。这个原始报文也就是私有报文,在GRE协议中叫做乘客协议,顾名思义,就像乘客一样。

                隧道有很多种,有二层隧道,比如VxLAN,也有三层隧道,比如GRE、IPSec等等,具体是二层隧道还是三层隧道,最简单明了的就是看overlay的原始报文是IP报文还是以太报文(是否有MAC地址),如果只有IP头,则是三层隧道,如果有MAC头,就是二层隧道。

                GRE就是一种比较简单的三层隧道。

                GRE安全机制:GRE本身提供两种基本的安全机制。

                • 校验和验证:校验和验证是指对封装的报文进行端到端校验。

                  若GRE报文头中的C位标识位置1,则校验和有效。发送方将根据GRE头及Payload信息计算校验和,并将包含校验和的报文发送给对端。接收方对接收到的报文计算校验和,并与报文中的校验和比较,如果一致则对报文进一步处理,否则丢弃。

                  隧道两端可以根据实际应用的需要决定配置校验和或禁止校验和。如果本端配置了校验和而对端没有配置,则本端将不会对接收到的报文进行校验和检查,但对发送的报文计算校验和;相反,如果本端没有配置校验和而对端已配置,则本端将对从对端发来的报文进行校验和检查,但对发送的报文不计算校验和。

                • 识别关键字:识别关键字(Key)验证是指对Tunnel接口进行校验。通过这种弱安全机制,可以防止错误识别、接收其它地方来的报文。

                  RFC1701中规定:若GRE报文头中的K位为1,则在GRE头中插入一个四字节长关键字字段,收发双方将进行识别关键字的验证。

                  关键字的作用是标志隧道中的流量,属于同一流量的报文使用相同的关键字。在报文解封装时,GRE将基于关键字来识别属于相同流量的数据报文。只有Tunnel两端设置的识别关键字完全一致时才能通过验证,否则将报文丢弃。这里的“完全一致”是指两端都不设置识别关键字,或者两端都设置相同的关键字。

                  最后,GRE协议并不提供数据加密和身份验证等安全机制,因此在使用时需要考虑安全性问题。

                  在RFC1701中规定了GRE Header的格式,如下图所示:

                  C(bit0):校验和存在位,置位1则表示Checksum存在且包含有效信s息。

                  R(bit1):路由存在位,置位1则表示Offset和Routing存在且包含有效信息。

                  K(bit2):key存在位,置位1则表示Key存在且包含有效信息。

                  S(bit3):序列号存在位,置位1则表示Sequence Number存在且包含有效信息。

                  s(bit4):Strict Source route,置位1则表示,路由信息全部为严格源路由。

                  bit5~bit15都默认置0。

                  注:如果C和R任意一个置位1,则表示Checksum和Offset都存在GRE报文中。——???

                  Protocol Type(2字节): “协议类型”字段包含负载报文的协议类型。通常,该值将是数据包的以太网协议类型字段。下面列出了当前定义的协议类型。其他的值可以在其他文档中定义。

                  Offset(2字节):offset字段表示要检测的主源路由表项从“Routing”字段开始到第一个字节的偏移量。当Routing present位或Checksum present位设置为1时,该字段才会出现。只有当Routing present位设置为1时,该字段才会包含有效的信息。

                  Checksum(2字节):校验和字段包含GRE报文头以及负载。

                  Key(4字节):Key字段长度为四个字节,是由封装者封装在报文中。可以被接收者用来验证报文的来源。

                  Sequence Number(4字节):序列号字段长度为四个字节,是由封装者封装在报文中。接收者使用序列号来对接收的报文进行排序.

                  Routing(变长):Routing的长度是可变的,是由一系列的SREs(Source Route Entries)组成的,其报文结构如下图所示:

                  RFC总结之GRE协议

                  SCTP

                  ICMP

                  IGMP

                  STP/RSTP/MSTP

                  Spanning Tree Protocol,即 STP 协议,用于为以太网构建无环路的逻辑拓扑。

                  STP 协议的作用

                   STP 协议通过阻塞交换机端口,令其不再转发数据帧,使得环路被裁剪成一棵树,达到 在逻辑上消除环路的目的 在链路发生故障后,激活备份链路,及时恢复网络连通性。

                  消除环路:允许网络物理拓扑中存在备份链路,消除逻辑拓扑上的二层环路

                  备份链路:发生故障后使用备份链路,及时恢复网络,提高网络的可靠性

                  STP 协议的缺点

                    由上可知,当网络中的某个设备发生故障不可用时,需要等待所有的网络设备接收和传播 BPDU,重新选举根桥、根端口、指定端口和阻塞端口,收敛速度慢。而且在网络设备端口状态的转换过程中,数据流量会被阻塞,可能会加剧延时。除此之外,STP 协议对局域网仅生成一棵树,对于所有 VLAN 都使用相同的拓扑。这意味着在多个 VLAN 环境中,可能存在不必要的阻塞端口。如果需要不同的拓扑或特定的 VLAN 配置,可能需要手动配置。

                  总结一下,STP 协议的缺点有以下两条:收敛速度慢,不支持 VLAN;

                  RSTP、MSTP 协议

                  针对 STP 协议缺点的改进,出现了 RSTP 和 MSTP 协议

                  RSTP 协议

                  RSTP 是 STP 的改进版本,它的主要目标是加速 STP 的收敛速度。

                  RSTP 引入了两种端口状态:指定端口(Designated Port)和替代端口(Alternate Port)。

                  RSTP 使用不同的 BPDU 格式和机制,以快速传播拓扑变化。

                  RSTP 的收敛速度较快,通常可以在数秒内响应拓扑变化,而不是 STP 的 30 秒或更长时间。

                  MSTP 协议

                  MSTP 是 STP 的另一种改进版本,旨在提供更大的灵活性,特别是在多 VLAN 环境下。

                  MSTP 引入了多个实例(Instance),每个实例可以关联到一个或多个 VLAN。

                  MSTP 允许管理员为每个实例配置独立的树状拓扑,支持不同 VLAN,从而提高网络的灵活性。

                  MSTP 使用单一 BPDU 格式,但在每个实例中维护独立的树状拓扑,因此可以减少网络开销。

                  STP vs RSTP vs MSTP

                  STP有两种报文结构,一种是配置BPDU(configuration BPDU),另一种拓扑变化通知BPDU(TCN BPDU)

                  VxLAN

                  VxLAN是什么?

                  VxLAN(Virtual eXtensible LAN,可扩展虚拟局域网络)是基于IP网络、采用“MAC in UDP”封装形式的二层VPN技术。VxLAN可以基于已有的服务提供商或企业IP网络,为分散的物理站点提供二层互联,并能够为不同的租户提供业务隔离。VXLAN主要应用于数据中心网络。

                  VXLAN具有如下特点:

                  • 支持大量的租户:使用24位的标识符,最多可支持2的24次方(16777216)个VxLAN,使支持的租户数目大规模增加,解决了传统二层网络VLAN资源不足的问题。
                  • 易于维护:基于IP网络组建大二层网络,使得网络部署和维护更加容易,并且可以充分地利用现有的IP网络技术,例如利用等价路由进行负载分担等;只有IP核心网络的边缘设备需要进行VxLAN处理,网络中间设备只需根据IP头转发报文,降低了网络部署的难度和费用。

                    (目前,设备只支持基于IPv4网络的VXLAN技术,不支持基于IPv6网络的VXLAN技术.——为啥?)

                    VXLAN由RFC7348定义,这是2014年定稿的一个协议。

                    VXLAN报文格式:

                    VXLAN报文的封装格式为:在原始二层数据帧外添加8字节VXLAN头、8字节UDP头和20字节IP头。其中,UDP头的目的端口号为VXLAN UDP端口号(缺省为4789)。

                    VXLAN头主要包括两部分:

                    · 标记位:“I”位为1时,表示VXLAN头中的VXLAN ID有效;为0,表示VXLAN ID无效。其他位保留未用,设置为0。

                    · VNI: VXLAN Network Identifier,VXLAN 网络标识符。即VXLAN ID:用来标识一个VXLAN网络,长度为24比特。

                    VXLAN与VLAN之间有何不同?

                    VLAN不足点:

                    (1)VLAN作为传统的网络隔离技术,在标准定义中VLAN的数量只有4000个左右,无法满足大二层网络的租户间隔离需求。(2)VLAN的二层范围一般较小且固定,无法支持虚拟机大范围的动态迁移。

                    VxLAN改进点:

                    (1)VXLAN完美地弥补了VLAN的上述不足,一方面通过VXLAN中的24比特VNI字段,提供多达16M租户的标识能力,远大于VLAN的4000;

                    (2)VXLAN本质上在两台交换机之间构建了一条穿越基础IP网络的虚拟隧道,将IP基础网络虚拟成一个巨型“二层交换机”,即大二层网络,满足虚拟机大范围动态迁移的需求。

                    虽然从名字上看,VXLAN是VLAN的一种扩展协议,但VXLAN构建虚拟隧道的本领已经与VLAN迥然不同了。

                    NVGRE

                    NVGRE:Network Virtualization using Generic Routing Encapsulation,网络虚拟化通用路由封装;NVGRE是一种用于数据中心网络虚拟化的技术,与VXLAN类似,但使用了不同的封装协议。

                    NVGRE报文的封装格式为:在原始二层数据帧外添加8字节GRE头和20字节IP头。其中,GRE头主要包括以下几部分:

                    · 标记位:4比特。第一位(Checksum Present位)为0,表示GRE头不携带GRE校验和;第二位未定义;第三位(Key Present位)为1,表示GRE头中携带VSID;第四位(Sequence Number Present位)为0,表示GRE头不携带序列号。

                    · 版本:GRE协议版本号。

                    · 协议类型:GRE头内封装的载荷数据的协议类型,取值为0x6558,表示透明以太网桥接,即GRE头内封装二层以太网数据帧。

                    · VSID(Virtual Subnet Identifier,虚拟子网标识符):用来标识一个NVGRE网络,长度为24比特。

                    GENEVE

                    GENEVE(Generic Network Virtualization Encapsulation,通用网络虚拟化封装),是一种虚拟化隧道通信技术,定义于RFC 8926。

                    相比于之前类似的技术,GENEVE的一点重大区别在于:协议的元数据本身是可扩展的。GENEVE提供了可扩展的GENEVE header,让业务更加灵活。

                    IPv4的Geneve数据包格式如下:

                    字段长度(bit)含义
                    Version2版本号,目前为0
                    Opt Len6表明Variable Length Options的长度,这里的一位代表Variable Length Options的4字节。因为只有6bit,所以Variable Length Options最多是252(63*4)字节。
                    O1表明这是一个OAM包,包含了控制信息,而非数据。Endpoint可以根据这个bit来优先处理这个包。
                    C1表明在Variable Length Options里面,存在一个或者多个Critical的option。当C被置位时,Variable Length Options必须被解析,如果当前Endpoint不支持GENEVE解析,那么应该丢弃数据包。如果C没有被置位,那么Endpoint可以根据Opt Len直接丢弃所有的Variable Length Options。
                    Reserved6保留字段
                    Protocol Type16被封装的协议类型,如0x6558代表以太网
                    VNI24同VxLan的VNI,虚拟网络标识符
                    Variable Length Options可变长,长度为Opt Len*4可扩展的元数据

                    这里的O和C字段是出于性能考虑,GENEVE报文的可扩展性很好,那就意味着其长度可能比较长,处理起来就比较耗资源,加入这两个字段可以使得Endpoint能够更灵活的处理数据。

                    在兼容性上,如果不考虑Variable Length Options,GENEVE与VxLAN是不冲突的,一些现有的针对VXLAN的优化可以直接应用在GENEVE上。

                    在考虑ECMP的情况下,ECMP设备看到的不是虚机的IP/MAC,而是Tunnel Endpoint的IP/MAC。也就是说,连接到同一台Tunnel Endpoint的机器的外层报文除了UDP port都是相同的。GENEVE协议认为应该使用source port的整个16bit(而不是常用的50000-65535)做Overlay流区分(RFC 8926 Section 2.3)

                    详细来看Geneve的封装帧,从外到里依次是:

                    外层以太头 > 外层IP头(V4或V6) > 外层UDP头 > Geneve头(变长) > 内层以太头 > Payload > 外层以太头的FCS

                    当中UDP的目标port默认是IANA分配的6081。而且支持可配置。UDP的校验和必须计算正确。也可配置为0。

                    Geneve支持单播、多播和广播。

                    GENEVE产生的背景:

                    网络虚拟化最基础的技术莫过于分层(Overlay、Underlay),要实现分层有两种手段。一个是映射(Mapping),一个是封装(Encapsulation)。

                    映射,主要思路是转发时替换报文语义,怎样替换将须要设备进行查询。

                    封装,则是把须要的报文语义加入到网包中。处理的时候一层层的解封装就可以,尽量对设备透明。

                    不少协议都实现了封装的部分或完整功能。包含IP-in-IP、Vlan、MPLS、VXLAN、NVGRE、STT等。这些协议各有各的特点,不少都是为了简单地隔离或者通过隧道连通不同网络。特别是后面几种。设计理念大同小异,仅仅是实现细节不同。

                    对通用的封装协议标准的需求已经越来越强烈。于是有了Geneve: Generic Network Virtualization Encapsulation。Geneve的出发点是解决封装时候加入的metadata信息问题(究竟多少位。该怎么用),尝试适应各种虚拟化场景,Underlay的协议是最通用的IP协议(准确的说是UDP)。

                    跟大部分的封装协议类似。实现Geneve一般须要两类设备:隧道终端(tunnel endpoints)和传输设备(transit devices)。前者用来处理封装头终止隧道,后者则是非必需的。一般是支持IP转发的设备。

                    之前介绍过通用路由封装协议GRE和虚拟可扩展局域网VxLAN,他们都是隧道协议的一种实现。

                    这两种协议的初衷和实现形式都是类似的。从初衷上说,这两种协议都是想实现一种对原始网络数据的一种扩展和封装:以一定的格式封装原始网络数据,再辅以一定的元数据(metadata),来实现附加的功能。例如,VxLAN中的网络标识符VNI就是一种元数据,实现的功能是对租户进行区分。

                    但是,随着网络的扩展以及业务的发展,有时候需要一种符合自己网络情况以及业务逻辑的协议,例如采用自己独特的业务元数据。这时候就需要一种技术来实现一种通用的封装方式,来符合自己的需求。这种封装最好可长可短,来实现自己的逻辑

                    GENEVE(Generic Network Virtualization Encapsulation) 是2016-17年开源界出现的一种新型开源数据虚拟化封装(隧道)协议,它设计的初衷就是解决当前数据传输缺乏灵活性,难以满足用户在安全,在业务应用支撑上的各种灵活要求的。2020年11月,IETF(全球互联网技术任务组)正式出版了详细的白皮书(RFC:8926),标志着该技术已经足够成熟。

                    1588

                    PTP(Precision Time Protocol)报文使用 UDP/IP 传输机制封装在以太网帧中,或者直接封装在以太网帧中的第 2 层。

                    PTP over IEEE 802.3/Ethernet(IEEE 1588v2协议附录F)

                    PTP over UDP over IPv4(IEEE 1588v2协议附录D)

                    PTP over UDP over IPv6(IEEE 1588v2协议附录E)

                    UDP/IP 封装

                    1588 的消息(v1 和 v2)可以使用 UDP/IP 多播(组播)消息进行传输。

                    下面的表格展示了为 PTP 定义的 IP 多播分组。该表还根据 RFC 1112(IP 的最后三个字节为固定值 01-00-5E)显示了他们各自的 MAC 层多播地址映射。

                    以太网封装 (PTPv2)

                    除了使用 UDP/IP 帧,IEEE 1588v2 还定义了使用 ethertype = 0x88F7 的本地以太网帧格式。以太网帧的有效负载直接包含 PTP 数据包,以 PTPv2 报头开始。

                    除此之外,版本 2 还增加了一个对等的延迟机制,以允许沿多个节点上的路径测量单个点对点链接之间的延迟。以下组播域也在 PTPv2 中定义。


                    致谢:

                    以上部分内容整理自网络,仅供学习,特此深表感谢,如有侵权,告知删除!