BGP（2）：BGP 的报文格式

桃扇骨 2023-08-17 17:08 88阅读 0赞

**10.2 BGP 的报文格式**

BGP 的报文承载于 TCP 报文，如图10-7所示。

![20190930144012693.png][]

图10-7 BGP 报文承载于 TCP 报文

BGP 报文所对应的 TCP 端口号是179。与其他协议一样，BGP 报文也分为2部分：BGP Header、BGP Data。下面我们分别讲述。

**10.2.1 BGP 报文头格式**

BGP 报文分为4种类型，所有类型的 BGP Header，都是一样的格式，如图10-8所示。

![2019093014404655.png][]

图10-8 BGP Header 报文格式

BGP Header 包括3个字段：Marker、Length、Type，下面我们分别讲述。

*  Marker

Marker 占有16个字节，其值全部设为“1”（This 16-octet field is included for compatibility; it MUST be set to all ones. RFC 4271）。

*  Length

Length 字段占有2个字节，其标识整个 BGP 报文的长度（计量单位是“字节”），等于 BGP Header 长度与 BGP Data 长度之和。

*  Type

Type 字段占有1个字节，标识 BGP 的报文类型。BGP 报文类型一共有4种。

（1）Open（Type = 1）: 用于建立BGP对等体之间的连接关系

（2）Keepalive（Type = 2）: 周期性地向BGP邻居发出Keepalive消息, 用来保持 TCP连接的有效性

（3）Update（Type = 3）: 携带的是路由更新（删减、增加）信息

（4）Notification（Type = 4）: 当BGP检测到错误状态时, 就向对等体发出Notification消息, 之后BGP连接会立即被关闭

BGP Update 报文（Type = 3），就是“传说”中的 BGP 路由通告报文。由于另外3种报文并不是本章的重点，所以接下来我们值讲述 BGP Update 的报文格式。

**10.2.2 BGP Update报文格式**

BGP 路由通告，简单地说就是：路由器将存放于自身 BGP 表中的路由信息，通过 BGP Update 消息，发送给它的 BGP 邻居（peer）。

不过需要强调的是，BGP 每次通告的是它的“变量”路由信息，而不是全量。这意味着路由器第1次将自己所有 BGP 路由信息通告给其邻居以后，后续的路由通告，只须通告“变化”的路由信息即可。

所谓“变化”，指的就是当前的路由信息与上次通告时的路由信息相比，哪些是“删除”的路由，哪些是“新增”的路由。

所以我们会在 BGP Update 报文中看到“删除路由”、“新增路由”等相关字段，如图10-9所示。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70][]

10-9 BGP Update 消息报文格式

图10-9所示的 BGP Update 报文格式，分为3个部分。

（1）撤销路由的信息，包含2个字段：Withdrawn Routes Length，Withdrawn Routes。当上次通告的路由，有些路由已经无效时，本次路由通告需要靠这两个字段告知邻居将这些无效的路由撤销（删除）

（2）新增路由的路径属性，包含两个字段：Total Path Attribute Length，Path Attributes。这个表示新增的路由，除了目的网段以外的其他相关的路径属性

（3）新增路由的可达信息，包含1个字段：Network Layer Reachability Information，表示的是新增路由的目的网段信息（意思是，这些网段的路由是可达的）。

下面我们分别讲述这3部分内容。

**10.2.2.2 撤销路由的信息**

由于所要撤销的路由（Withdrawn Routes）是一个变长字段（包含 0~n 个撤销路由），所以需要用 Withdrawn Routes Length（撤销路由长度，占用2个字节）来标识所有的撤销路由的长度（计量单位是字节）。

当然，如果 Withdrawn Routes Length = 0，则表示没有需要撤销的路由（Withdrawn Routes Length 字段的后面，也不会再有 Withdrawn Routes 字段）。

Withdrawn Routes，是一个列表（List），包含 N 个二元组“<Length, Prefix>”，其数据结构如图10-10所示。

![20190930145409576.png][]

图10-10 Withdrawn Routes 数据结构

图10-10表达了 n 个二元组<Length, Prefix>，其中 Length 占有1个字节，Prefix 是变成的，其长度由 Length 字段的值表示（计量单位是“bits”）。

1个路由表项中表达目的地址的方法是“网段 + 掩码长度”，二元组(Length, Prefix)中的“Length”表述的就是掩码长度，“Prefix”表述的就是网络号。比如“1.1.1.0/24”用这种二元组的方法表示就是<24(length), 1.1.1(prefix)>，当然“1.1.1”要用bit的形式表示：111111100000000111111111（1 \* 2553 + 1 \* 2552 + 1 \* 255）。

如果二元组的 Length = 0（Prefix 也就不用填写了，因为也没地方填写了），那么意味着所有路由都撤销。

**10.2.2.3 新增路由的可达信息**

新增路由的可达信息（Network Layer Reachability Information，NLRI）的根本含义就是路由表项中的“目的地址”，所以它的数据结构与 Withdrawn Routes 是一样的，也是一个 list，包含 N 个二元组<Length, Prefix>。

NLRI 表示路由表项中的“目的地址”，那么路由表项中的“下一跳”该是什么呢？这就涉及到了“新增路由中的路径属性”。

**10.2.2.4 新增路由中的路径属性**

BGP Speaker 向它的邻居不能仅仅通告1个“目的地址”，最起码还要包含“下一跳”，这个路由表项才会完整。

BGP 将“下一跳”的信息放到了 BGP Update 报文中的“新增路由中的路径属性”字段。除了“下一跳”以外，“路径属性”还包括很多内容，而且非常复杂。

我们先从属性的分类讲起。

**1）路径属性的分类**

我们知道，一个 BGP Speaker，在收到邻居的路由通告（BGP Update 报文）时，还会继续通告给它的其他邻居（注意前面介绍过的 eBGP 和 iBGP 的区别）。这些属性分类，其目的是为了约束路由器是否支持这些属性，以及是否传递这些属性。

路径属性一共分为4类。

（1）Well-known mandatory（公认/必选）。这些属性必须支持，而且必须体现在 BGP Update 报文中，而且必须再次传递给邻居（在接下来的路由通告报文中，必须包含这些属性），如果需要再次通告给邻居的话

（2）Well-known discretionary（公认/自选）。这些属性必须支持，但是第1个路由公告路由时，不是必须体现在 BGP Update 报文中.如果第1个路由公告路由时，包含了这些属性，那么后续路由通告中必须再传递给邻居

（3）Optional transitive（可选/可传递）。这些属性不要求必须支持。有的路由器支持，有的路由器不支持，这没关系。当1个支持此属性的路由器，通告给一个不支持此属性的路由器时，这个不支持此属性的“吃瓜”路由器，再次通告路由时，是丢弃还是传递此属性，取决于报文中其中一个 bit 的值（1，必须传递；0 必须不传递）

（4）Optional non-transitive（可选/非传递）。这些属性不要求必须支持。有的路由器支持，有的路由器不支持，这没关系。当一个支持此属性的路由器，通告给一个不支持此属性的路由器时，这个不支持此属性的“吃瓜”路由器，再次通告路由时，必须丢弃此属性，不能在 Update 报文中带上此属性

以上所说的分类，其实是表达了路由通告的两个行为：是否必须支持、是否必须传递，如表10-1所示。

表10-1  路径属性分类的含义

<table style="width:568px;"> 
 <tbody> 
 <tr> 
 <td>&nbsp;</td> 
 <td> 是否必须支持 </td> 
 <td> 是否必须传递 </td> 
 </tr> 
 <tr> 
 <td> 公认/强制 Well-known mandatory </td> 
 <td> 必须支持 </td> 
 <td> 必须传递 </td> 
 </tr> 
 <tr> 
 <td> 公认/自定 Well-known discretionary </td> 
 <td> 必须支持 路由器必须支持，但是第1个公告路由的路由器，可以不带上这些属性 </td> 
 <td> 必须传递 如果第1个公告路由的路由器，没带上这些属性，那么所谓传递，无从谈起； 如果第1个公告路由的路由器，带上了这些属性，那么以后的路由通告，必须传递 </td> 
 </tr> 
 <tr> 
 <td> 可选/可传递 Optional transitive </td> 
 <td> N </td> 
 <td> 不一定 是否传递，取决于报文中有一个 bit 位设置的值：1，必须传递；0 必须不传递 </td> 
 </tr> 
 <tr> 
 <td> 可选/非传递 Optional non-transitive </td> 
 <td> N </td> 
 <td> 必须不能传递 </td> 
 </tr> 
 </tbody> 
</table>

从某种意义上讲，“必须支持”的属性，就是 BGP 协议规定的“公有属性”，不是“必须支持”的属性，就是厂商的私有属性，厂商可以任意扩展。

当前 BGP Update 消息中的路径属性，我们举例如表10-2所示。

表10-2  路径属性举例

<table style="width:568px;"> 
 <tbody> 
 <tr> 
 <td> 属性名称 </td> 
 <td> 属性类型 </td> 
 </tr> 
 <tr> 
 <td> Origin </td> 
 <td> Well-known mandatory </td> 
 </tr> 
 <tr> 
 <td> AS_Path </td> 
 <td> Well-known mandatory </td> 
 </tr> 
 <tr> 
 <td> Next hop </td> 
 <td> Well-known mandatory </td> 
 </tr> 
 <tr> 
 <td> MED </td> 
 <td> Optional non-transitive </td> 
 </tr> 
 <tr> 
 <td> Local_Preference </td> 
 <td> Well-known discretionary </td> 
 </tr> 
 <tr> 
 <td> Atomic_Aggregate </td> 
 <td> Well-known discretionary </td> 
 </tr> 
 <tr> 
 <td> Aggregator </td> 
 <td> Optional transitive </td> 
 </tr> 
 <tr> 
 <td> Community </td> 
 <td> Optional transitive </td> 
 </tr> 
 <tr> 
 <td> Originator_ID </td> 
 <td> Optional non-transitive </td> 
 </tr> 
 <tr> 
 <td> Cluster_List </td> 
 <td> Optional non-transitive </td> 
 </tr> 
 <tr> 
 <td> Destination Pref (MCI) </td> 
 <td>&nbsp;</td> 
 </tr> 
 <tr> 
 <td> Advertiser (Baynet) </td> 
 <td>&nbsp;</td> 
 </tr> 
 <tr> 
 <td> Rcid-Path (Baynet) </td> 
 <td>&nbsp;</td> 
 </tr> 
 <tr> 
 <td> MP_Reach_NLRI </td> 
 <td>&nbsp;</td> 
 </tr> 
 <tr> 
 <td> MP_Unreach_NLRI </td> 
 <td>&nbsp;</td> 
 </tr> 
 <tr> 
 <td> Extended_Communities </td> 
 <td>&nbsp;</td> 
 </tr> 
 </tbody> 
</table>

**2）路径属性的数据结构**

BGP Update 消息中，有两个字段表示路径路径属性（如图10-9所示）：Total Path Attribute Length，Path Attributes。

Total Path Attribute Length 占有2个字节，它指明了 Path Attributes 字段的所有长度（计量单位是字节）。

Path Attributes 是个变长字段，它是一个 list，包含 N 个三元组<attribute type, attribute length, attribute value>。下面我们分别介绍这3个字段。

*  attribute type

attribute type 占有2个字节。attribute type，又细分为2个字段。第1个字段是Attr.Flags（属性标签），第2个字段是Attr.Type Code（属性类型值），如图10-11所示。

![20190930150119807.png][]

图10-11 Attribute Type 的数据结构

Attr.Type Code，是一个整数，表示一个属性类型，比如“ORIGIN”属性的 Attr.Type Code = 1。

而 Attr.Flags 则比较复杂，其前4个 bit，每个 bit 都表示1个含义（后4个 bit，暂时没有使用），如图10-12所示。

![20190930150336504.png][]

图10-12 Attr. Flags 报文结构

这8个 bit 的解释，如下表所示。

表10-3  Attr. Flags 各 bit 的含义

<table style="width:568px;"> 
 <tbody> 
 <tr> 
 <td> bit </td> 
 <td> 含义 </td> 
 </tr> 
 <tr> 
 <td> 0 Optional </td> 
 <td> 如果值等于1，则表示属性是可选的（optional） 如果值等于0，则表示属性是公认的（well-known） </td> 
 </tr> 
 <tr> 
 <td> 1 Transitive </td> 
 <td> 针对可选属性，如果值为1，则表示必须传递，如果值为0，则表示必须不传递 针对 well-known 属性，其值必须设置为1（必须传递） </td> 
 </tr> 
 <tr> 
 <td> 2 Partial </td> 
 <td> 针对 Optional Transitive 属性，如果值为1，表示这个属性仅仅是部分，如果值是0，表示这个属性已经是完整的（complete） 针对 well-known 属性 和 optional non-transitive 属性，其值必须为0（complete） </td> 
 </tr> 
 <tr> 
 <td> 3 Extend Length </td> 
 <td> 如果值等于0，则表示接下来的属性长度字段占用1字节 如果值等于1，则表示接下来的属性长度字段占用2字节 </td> 
 </tr> 
 <tr> 
 <td> 4~7 unused </td> 
 <td> 4~7 bit，没有使用，必须设置为0 </td> 
 </tr> 
 </tbody> 
</table>

通过表10-3可以看到，我们在“属性的分类”中所讲述的“well known/optional、transitive/non-transitive”，实际上就是由这 4 个 bits 来表示。

*  attribute length

attribute length，可能占有1个字节，也可能占有2个字节，取决于表10-3中的“Extend Length”这个 bit 的值。如果 Extend Length = 0，attribute length 占有1个字节，如果 Extend Length = 1，attribute length 占有2个字节。

attribute length 表示的是 attribute value 的长度（计量单位是字节）

*  attribute value

attribute value 是一个变长字段，表示属性的值。至于属性的值具体代表什么含义，与具体的属性类型相关。

**3）路径属性的说明**

表10-2中列举了 16 个路径属性，这里我们挑选几个比较重要的属性进行介绍。

*  Origin

Orgin 是一个 Well-known mandatory 属性，Attr.Type Code = 1。它指的是这次路由通告（Update 报文）中的路由来源是什么，不同的值，代表不同的来源。

（1）IGP（attribute value = 0），表示 NLRI 来源于本 AS 的 IGP 导入

（2）EGP（attribute value = 1），表示 NLRI 来源于 EGP（EGP 已经废弃）

（3）INCOMPLETE（attribute value = 1），表示 NLRI 从其他方式获得，比如路由重分布（redistribute）

*  AS\_Path

AS\_Path 是一个 Well-known mandatory 属性，Attr.Type Code = 2。

AS\_Path 的数据结构是一个三元组  <path segment type, path segment length, path segment value>。这3个字段的含义如下。

（1）path segment type，表明 path segment value 里的 AS ID 的排列顺序。

如果 path segment type = 1，表明是 AS\_SET，无序排列；

如果 path segment type = 2，表明是 AS\_SEQUENCE，顺序排列。

值得一提的是，这个顺序排列，其实是倒叙排列。比如通告顺序是：R1(AS1) -> R2(AS2)，R2(AS2) -> R3(AS3)，

R3(AS3) -> R4(AS4)，那么 path segment value = AS4，AS3，AS2，AS1。

（2）path segment length，1个字节长，表明 path segment value 中包含多少个 AS ID（1个字节长，意味着最多有 255 个 AS ID）。

（3）path segment value，是一批 AS ID，表明到达此次通告中的路由，所经过的 AS。这是个变长字段，取决于有多少个 AS ID，每个 AS ID 占用2个字节

AS\_Path 的赋值规则是如下。

（1）如果是 iBGP 通告，则不会改变原来的 AS\_Path 值，保持不变，通告下去。

（2）如果是 eBGP 通告，则在“path segment value”里面 insert 自己的 AS ID（注意区分path segment type）。

AS\_Path 有两大作用，第1个作用是防止 eBGP 路由通告环路，第2个作用是在 BGP 选择最优路径时，发挥作用。

第2个作用，我们放到10.3节讲述，这里我们先讲述第1个作用（防止 eBGP 路由通告环路）。

eBGP 的路由通告是“一传十十传百”，这有可能会引发路由回路。为了阅读方便，我们将图10-4重新贴一下，如图10-13所示。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 1][]

图10-13 eBGP 的路由通告

图10-13中，R1 自己的路由，经过“R1-R2-R3-R4-R1”这样一个循环，又通告给自己。然后，R1 再通告给 R2 ...... 如此循环反复，无穷无尽。而且，图10-13这样的场景，不仅会造成路由通告环路，还会引发路由环路。

eBGP 解决这个问题的方法就是，在 BGP Update 消息中，在路径属性里附加上 AS\_Path 这个字段。比如 R1 通告给 R2，AS\_Path 的值是“AS1”（AS\_Path 的值实际上是1个三元组列表，这里只是简单示例）。这个路由再通过 R2 通告给 R3 时，AS\_Path 的值是“AS2-AS1”，以此类推，当这个路由通过 R4 通告给 R1 时，AS\_Path 的值变成了“AS4-AS3-AS2-AS1”。当 AS1 得到这个路由通告时，它发现 AS\_Path 里面有自己“AS1”，那么它就将这条路由丢弃。这样就避免了环路。

*  Next\_Hop

Next\_Hop 是一个 Well-known mandatory 属性，Attr.Type Code = 3。

BGP Speaker，会将路由通告给它的 peer。那么其所通告的路由中的下1跳（Next\_Hop）应该是什么呢？我们从1个例子入手来讲解。如图10-14所示。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 2][]

图10-14 Next\_Hop 组网图

我们先描述一下图10-14中的 TOPO 关系，如下所示。

（1）R1(1.1.1.1/24)/R3(1.1.3.3/24)，iBGP peer

（2）R1(1.1.1.1/24)/R4(1.1.1.4/24)，eBGP peer

（3）R4(1.1.4.4/24)/R5(1.1.4.5/24)，eBGP peer

（4）R5(1.1.5.5/24)/R6(1.1.5.6/24)，iBGP peer

（5）R3 连接 8.8.8.0/24 网段

Next\_Hop 的赋值规则如下。

（1）iBGP 通告，目的地址也在 iBGP 这个 AS 域内（图10-14中 R3 通告给 R1，目的网段 8.8.8.0/24），Next\_Hop 就是宣告路由器的地址（1.1.3.3）

（2）iBGP 通告，目的地址不在 iBGP 这个 AS 域内（图10-14中 R5 通告给 R6，目的网段 8.8.8.0/24），Next\_Hop 是上一个 eBGP 宣告时的宣告者地址（图10-14中，上一个 eBGP 宣告，是 R4 宣告给 R5，Next\_Hop 是 R4 的 IP 地址：1.1.4.4）

（3）eBGP 通告，Next\_Hop 就是宣告路由器的地址（图10-14中：R1 通告给 R4，目的网段 = .8.8.0/24，Next\_Hop = 1.1.1.1；R4 通告给 R5，目的网段 = 8.8.8.0/24，Next\_Hop = 1.1.4.4）

我们把 Next\_Hop 属性叠加到图10-14中，可以有更加直观的认识，如图10-15所示。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 3][]

图10-15 Next\_Hop 示意图

*  Multi\_Exit\_Disc

Multi\_Exit\_Disc 是 Multi\_Exit\_Discriminate 的缩写，有时也简写为 MED。它是一个  optional non-transitive 属性，Attr.Type Code = 4。

MED 是一个 4 字节的无符号整数，正如其名称“Multi\_Exit\_Discriminate（多出口辨别）”所暗示的那样，它的目标确实也就是在路由选择时，帮助 BGP 选择哪个出口，如图10-16所示。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 4][]

图10-１6 MED 示意图

图10-16是1个简化的组网图，而且其他条件都不考虑，只考虑 MED 这一个因素。图10-16中，R1/R2，R1/R3，分别建立 eBGP peer。R2 与 R3，都向 R1 公告了路由，目的网段是 8.8.8.0/24，下一跳分别是 R2，R3。这样，R1 就会有两条 BGP 路由，都是前往 8.8.8.0/24，但是下一跳分别是 R2 和 R3。

现在问题来了，R1 该选择哪一个作为下一跳？

BGP 在选择路由时，在其他条件都相同的情况下，会优先选择 MED 小的那条路由。也就是说，图10-16中，BGP 优先会选择 R2 作为下1跳（去往 8.8.8.0/24）。

*  Local\_Pref

Local\_Perf 是 Local\_Preference的缩写，是一个 well-known 的属性，Attr.Type Code = 5。

Local\_Perf（本地优先级），也是“人如其名”，只会在1个 AS 域内的 iBGP 路由通告中传递，不会在 eBGP 路由通告中传递。如果哪位“大哥”故意在 eBGP 通告中附带了这个属性，那么接收者，也得忽略并丢弃这个属性。

Local\_Perf 这个属性的目的，也是为了选路，如图10-17所示。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 5][]

图10-１7 Local\_Pref 示意图

我们先描述一下图10-17中的 TOPO 关系，如下所示。

（1）R4/R2、R4/R3，分别是 eBGP peer

（2）R2/R1、R3/R1，分别是 iBGP peer

（3）R4 能够到达 8.8.8.0/24 网段

图10-17中，R1 所学习到 BGP 路由信息中，去往 8.8.8.0/24 网段的有2条路由，这2条路由，体现在出接口不同（不同的接口，对应着不同的 iBGP peer）。

那么 R1 会选择哪条路由呢？

BGP 为了解决这个问题，提出了 Local\_Pref 属性。Local\_Pref 是1个 4 字节无符号整数，它的值代表一个度量（metric），值越大，优先级越高，路由选择时，就会优选。

图10-17中，如果其他条件都一样，那么 R1 就会选择出接口 inf1，即通过 R2 出去。

[20190930144012693.png]: /images/20230808/1deb5bf9abec4d3192342d1daef965e7.png
[2019093014404655.png]: /images/20230808/8c763b02e50b4e838fc421be18d93a27.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70]: /images/20230808/c436080418f840c4aad5deed8aa58399.png
[20190930145409576.png]: /images/20230808/507aa7fbba4747a9aa771e23b51949ca.png
[20190930150119807.png]: /images/20230808/7029cb1cbc854eaaad4d8cc11b3cac7d.png
[20190930150336504.png]: /images/20230808/6522d4fb927140cbb9da64c1d7b37da0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 1]: /images/20230808/378d0844dbc445edb20dbf0e17666f96.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 2]: /images/20230808/1e77402810f546e3b095bc342224ac40.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 3]: /images/20230808/028a18e7d6054370826db3d61df2ae4e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 4]: /images/20230808/da9d57cc48e842da894010cb6d734756.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FybWxpbnV4d3c_size_16_color_FFFFFF_t_70 5]: /images/20230808/db55b3133c044677971e7ed4dec197d2.png