Datacom-HCIE

网络工程

发布日期: 2023-05-20

HCIE Datacom RS 部分

IGP高级特性

在常规网络中，OSPF协议、ISIS协议本身已经足够使用，但在有巨大流量通过或网络拓扑不稳定的非常规网络对路由协议有更高的要求。

高级特性分快速收敛和路由控制两种，在常规网络中几乎不会使用

OSPF高级特性

快速收敛

OSPF快速收敛是为了在路由或拓扑变化时提高收敛速度的扩展特性，包括：RPC(部分路由计算)和智能定时器。以及用于OSPF故障快速收敛机制OSPF IP FRR（快速重路由）和与BGP联动

RPC-部分路由计算

RPC是OSPF预置的收敛机制，无需配置、默认开启

其内容为：当网络上路由发生变化时，只对变化的路由进行重新计算

如图：R5上新增一条直连网段，OSPF协议所在的网络拓扑没有变化，此时OSPF只将新增的直连网段加入SPF最短路径树，不会重新计算整个OSPF网络

如果网络拓扑发生变化（如OSPF网络中接入了新设备），RPC机制不生效，受到影响的OSPF区域重新收敛

智能定时器

在标准RFC2328协议中，通过如下两个规定来避免网络连接或者路由频繁动荡引起的过多占用设备资源的情况。

同一条LSA在1s内不能再次生成，LSA更新时间间隔为5s
LSA被接收的时间间隔为1s

基于这个规定，智能定时器有两种用途：

对于网络很稳定，并且对收敛时间要求比较高的网络中，没有必须按规定的定时器更新并计算LSA。

此时可以通过智能定时器将LSA更新、被接收时间间隔为0，加快拓扑收敛。
对于网络不稳定，拓扑和路由频繁变化的网络，每次网络变化设备都会发送LSA更新。设备本来就不好，还频繁进行拓扑计算，对于设备来说是一种冲击。

此时可以通过智能定时器控制路由计算的延迟时间，抑制LSA频繁更新导致网络的高频变化

总结：通过智能定时器来控制路由计算的延迟时间，达到对低频率变化快速响应，又能对高频率变化起到有效抑制的目的。

智能定时器命令配置：

# 设置LSA更新时间
ospf 1
 lsa-originate-interval intelligent-timer 5000 500 500
 基于LSA发送间隔使能智能定时器(intelligent-timer)
     更新LSA最长间隔1000ms,初始间隔500ms,基数间隔500ms(5000和500均为ensp缺省值)
     根据设备的不同，智能定时器缺省值也不同

# 设置LSA接收时间间隔
ospf 1
 lsa-arrival-interval intelligent-timer 1000 500 500
 基于LSA接收间隔使能智能定时器(intelligent-timer)
 接收LSA最长间隔1000ms,初始间隔500ms,基数间隔500ms(1000和500均为ensp缺省值)
 根据设备的不同，智能定时器缺省值也不同

# 设置SPF计算时间间隔
ospf 1
 spf-schedule-interval intelligent-timer 10000 500 1000
 基于SPF最短路径树计算间隔使能智能定时器(intelligent-timer)
 计算SPF的最长间隔10000ms,初始间隔500ms,基数间隔1000ms(10000和500、1000均为ensp缺省值)
 根据设备的不同，智能定时器缺省值也不同

OSPF IP FRR

OSPF IP FRR 简称 FRR（快速重路由Fast reroute），其作用是在具有备份链路的网络中，利用LFA算法预先计算出备份路径，保存在转发表中。

在主链路故障时，备份链路直接承担流量转发工作，而无需OSPF重新计算路由、重新下发转发表

LFA计算备份链路的基本思路是：以可提供备份链路的邻居为根节点，利用SPF算法计算出到目的节点的最短距离。然后，按照RFC5286规定的不等式计算出开销最小且无环的备份链路。

为了防止环路，FRR的备份链路必须符合链路保护公式：

Disrance_opt(X,Y)指节点X,Y之间的最短路径开销

FRR命令配置：

ospf 1
 frr  # 使能frr
  loop-free-alternate  # 使能LFA算法
int g0/0/0
 ospf frr block  # 【可选】组织接口FRR功能

OSPF与BFD联动

OSPF与BFD联动有两种应用场景：

在对网络变化要求较高的网络中，使用BFD联动将OSPF收敛速度从秒级提升到毫秒级
对于链路中间存在二层交换机或集线器等两端设备无法感知整个链路的网络，两端设备使用BFD感知链路变化

如图，R1和R2之间有一个二层交换机，此时二层交换机G0/0/2口故障。

R1中路由虽然切到了备份链路R3,但在较长的一段时间内，和R2的邻居关系仍然保持Full状态

此时在R1和R2之间配置BFD，就可以快速检测故障

OSPF不支持与BFD单臂回声功能

OSPF联动BFD命令配置：

bfd  # 全局使能bfd功能
ospf 1
 bfd all-interfaces enable  # 打开OSPF BFD特性的开关
 当配置了全局BFD特性，且邻居状态达到Full时，OSPF为该进程下所有具有邻接关系的邻居建立BFD会话。

int g0/0/1
 ospf bfd enable  # 【可选】给指定接口打开OSPF BFD特性(控制BFD发布)
 ospf bfd block  # 【可选】阻止指定接口创建BFD会话

dis ospf 1 bfd session all  # 查看OSPF与BFD联动的会话信息

路由控制

OSPF路由特性部分包含以下内容：

等价路由

OSPF可以控制等价路由中路由条目的数量

ospf 1
 maximum load-balancing 8  # 设置一条等价路由最多包括8个路由条目

缺省为8，可以设置的范围是1-8（这个数值是以设备而定的，2vCPU的设备可以达到16条）

当组网中一条等价路由存在大于指定数量的路由条目时，按以下规则进行优选：

路由优先级：负载分担选取优先级值小的路由进行负载分担。
接口索引：如果接口的优先级相同，则比较接口的索引，负载分担选取接口索引大的路由进行负载分担。
下一跳IP地址：如果接口的优先级和接口索引都相同，则比较下一跳IP地址，负载分担选取IP地址大的路由进行负载分担。

nexthop [ip-address] weight [value]  # 设置路由优先级

同时，通过对不同的路由配置不同的收敛优先级，达到重要的路由先收敛的目的，提高网络的可靠性。

缺省路由

OSPF发布缺省路由有三种场景：

在普通区域，通过手动配置下发都可以产生一条5类LSA缺省路由，配置下发缺省路由的设备自动成为ASBR
在除NSSA区域的其他特殊区域，ABR都会自动发布一条指向骨干区域的3类缺省LSA
在NSSA区域，由于NSSA区域必须存在至少一个ASBR，使能NSSA后，由ABR生成一条指向骨干区域的缺省7类，此时ABR同时担任ABR和ASBR两种角色（NSSA不会产生缺省3类，但完全NSSA会）

有趣的是，OSPF自动生成的缺省路由通告者都是ABR中区域0(骨干区域)的接口

也就是说，并不是特殊区域自己向自己下发缺省路由，而是骨干区域向特殊区域下发缺省路由

手工下发缺省路由：

[R2-ospf-1]default-route-advertise ?
  always                  Always advertise default route
      无论本机是否存在激活的非本OSPF缺省路由，都会产生并发布一个描述缺省路由的5类LSA。
      同时设备不在计算来自其他设备的缺省路由
  permit-calculate-other  Always permit the local router to calculate the
                          default routes advertised by other routers
    本机必须存在激活的非本OSPF缺省路由时才会产生并发布一个缺省路由的5类LSA
    设备仍然计算来自于其他设备的缺省路由
  cost                    OSPF default cost
    设置缺省路由开销【可选】
  route-policy            Route policy
    按路由策略所配置的参数发布缺省路由【可选】
  summary                 Distribute a default route
    发布指定缺省路由的Type3 LSA,在选用该参数时，必须首先使能VPN，否则路由不能发布【可选】
  type                    Set OSPF metric type for the default routes
    指定外部路由的类型,1表示1类,2表示2类【可选】

如果没有配置permit-calculate-other参数，也没有配置always参数，则

本机存在激活的非本OSPF缺省路由时，设备不再计算来自其他设备的缺省路由。

本机不存在激活的非本OSPF缺省路由时，设备仍然计算来自于其他设备的缺省路由。

在OSPF中使用import-route不能引入外部路由的缺省路由

OSPF中外部路由类型分两类：

Type 1：外部路由开销＝本设备到相应的ASBR的开销＋ASBR到该路由目的地址的开销。

Type 2：外部路由开销＝ASBR到该路由目的地址的开销。（不计算内部路由开销）

OSPF默认是Type 1

Filter-lsa-out

通过路由策略route-policy或者Filter-policy只能过滤路由，不能过滤LSA，所以在非ABR、ASBR设备使用路由策略，或者在ABR、ASBR上路由策略方向配置错误，都不能完全过滤路由的目的（因为LSA仍然会继续传递）

OSPF提供Filter-LSA-out过滤器用于过滤3类、5类、7类LSA（其他LSA不能过滤）

Filter-lsa-out分在接口配置和在区域配置两种情况

# 在区域配置
ospf 1
 area 0.0.0.0
  filter 2000 export  # 根据ACL 2000过滤3类LSA(只能过滤三类)
 
# 在接口配置
[R1-GigabitEthernet0/0/0]ospf filter-lsa-out ? acl 2000
  all      Filter all types of LSAs  根据ACL 2000 过滤所有LSA(3\5\7类)
  ase      Filter type-5 ASE LSAs  ...过滤5类
  nssa     Filter type-7 NSSA LSAs  ...过滤7类
  summary  Filter type-3 Summary LSAs  ...过滤3类

其他特性

OSPF多进程

OSPF支持路由多进程，即在同一个路由器中开启多个OSPF进程，不同OSPF进程之间的交互分两种情况

在一个设备上存在两个OSPF进程

这种情况时两个OSPF进程可以当作两个协议看待，进程之间互不影响，互不干涉
在一条链路两端存在两个OSPF进程

这种情况时一个当作一个OSPF看待，如果链路两端在两个OSPF进程区域号相等，那么两个不同进程的OSPF可以正常建立邻居关系并交换路由

可以理解为，由于不在同一设备，进程之间的隔离失效了

这个原理可以应用于站点之间的OSPF扩展：

例如公司A想和公司B合并网络，有以下情况

A、B均运行OSPF但进程不同，直接将两台区域0设备直连宣告（链路两端不同进程但同一区域可以建立邻接关系交互路由）
A、B均运行OSPF但进程相同（这种情况可以不使用多进程，但一般配置多进程做策略）
A、B均运行OSPF但进程不同，区域也不同。
1. 分别在A、B公司开启一个相同的进程直连，然后做双点双向引入（这个最常用，因为网络不太可能总是理想情况，并且合并网络后仍然需要做策略）
2. 在A、B公司之间在添加一个路由器专门用于A、B公司的路由交互（A、B公司有钱可以做）

OSPF联动BGP

在存在BGP的OSPF网络中，容易出现这种情况：

如图，R1-R2链路故障，此时OSPF和BGP都通过R1-R3转发流量

这时链路恢复，由于OSPF收敛比BGP快，R1-R2率先建立OSPF邻接关系，BGP路由根据IGP从R1-R2转发

但BGP此时还没有启动，流量转发到R2后会发现没有路由条目，短时间内在R2处就产生了路由黑洞

为了避免这种情况，OSPF支持联动BGP，在BGP没有收敛完成前将R2置位Stub状态

Stub状态的ospf开销为最大值（缺省65534），避免流量从该路由器转发，直到BGP收敛完成

命令配置：

ospf 1
 stub-router [on-startup [持续时间]]  
 # 配置on-startup,表示在ospf启动时将设备置位Stub一段时间

严格来说不算联动，只能说是OSPF启动后等一段时间再进行转发，有这段等待时间，BGP自然就收敛完毕了

转发地址 FA

OSPF的5类LSA和7类LSA中包含一个特殊字段：FA

当FA为0时，表示去往该外部路由的数据发往ASBR

当FA不为0时，表示去往该外部路由的数据发往FA所标识的地址

如图，R2引入去往R1的静态路由，R4去往R1时如果发往5类LSA通告者，就产生了R4-R3-R2-R1的次优路径

这时OSPF会将FA字段设为到达目的地址的下一跳10.1.123.1。此时数据到达R3就会直接转发给R1

次优路径得以消除

FA是OSPF默认的机制，无需配置

其他FA应用场景：

OSPF GR（平滑重启）

GR是Graceful Restart的简称，又称平滑重启、优雅重启、完美重启。是一种保证在路由协议重启或者设备主备倒换时转发层面不受影响的技术，属于高可靠技术HA的一种

HA是一整套综合技术，主要包括冗余容错、链路保证、节点故障修复及流量工程。

GR是一种冗余容错技术，目前已经被广泛的使用在主备切换和系统升级方面，以保证关键业务的不间断转发

其核心思想是转控分离，在设备协议重启或者主备(主备板)倒换时保持转发层面不变，控制层面正常重启。直到控制层面重启完成，重新下发转发平面。

避免了路由振荡引发的业务中断，提高了整网的可靠性。

Grace-LSA

OSPF通过新增9类LSA Grace-LSA来支持GR功能，Grace-LSA用于在开始GR和结束GR时像邻居通过GR的时间、原因以及接口地址等内容

Grace-LSA 报文格式：

Opaque Type：表示Geace-LSA中TLVs字段的类型

Type=1：Grace Period TLV，长度4字节表示邻居进入GR Helper状态的最长保持时间，超过该时间周边邻居不再保持GR Helper状态【必须携带】

GR持续时间不超过1800s，GR成功或者失败都可以提前退出，不必等待超时才退出
Type=2：Graceful Restart Reason TLV，长度1字节，告知邻居重启的原因：【必须携带】
Type=3：IP Interface Address TLV，长度4字节，用于告知发送Grace LSA的接口IP地址，在网络上唯一标识一台重启设备

路由器在GR中分两种角色：

Restarter：重启路由器，要进行协议重启或者主备倒换的路由器，支持完全GR或者部分GR

完全GR（Totally GR）：指当有一个邻居不支持GR功能时，整个路由器退出GR状态。

部分GR（Partly GR）：指当有一个邻居不支持GR时，仅该邻居所关联的接口退出GR，其它接口正常进行GR过程。
Helper：协助重启路由器，重启路由器开启了GR功能的邻居都是Helper。支持有计划GR、无计划GR或者通过策略有选择支持GR。

有计划GR（Planned GR）：指手动通过命令使路由器执行重启或主备倒换。在进行重启或主备倒换前Restarter会先发送Grace-LSA。

无计划GR（UnPlanned GR）：路由器是由于故障等原因进行重启或主备倒换。

在主备倒换前不会事先发送Grace-LSA，而是直接开始主备倒换，在备板正常Up后才进入GR过程。

GR Session：GR Restarter和GR Helper之间的协商都是一个GR Session

以设备主备倒换为例：

对于有计划GR，主备倒换命令执行后，Restarter会首先向每个邻居发送一个Grace-LSA，通知邻居GR的开始以及GR的周期、原因等，然后进行主备倒换。无计划GR不会发送这个Grace-LSA
当备板正常Up后，立即发送一个Grace-LSA，通知邻居自己进入GR，包括GR的周期、原因等。然后会再向每个邻居连续发送5个Grace-LSA。（连续发送5个是为了确保邻居收到该Grace-LSA【因厂商而异】）
GR过程中，Helper会维护和Restarter的邻接关系，保证转发表不变
Helper和Restarter重新建立邻接关系，GR完成
Restarter正常退出GR，重新计算路由。Helper收到Flush Grace-LSA，退出Helper，生成Router-LSA正常交互LSA

GR配置：

ospf 1 
 opaque-capability enable   # 使能opaque功能，使设备可以收发Grace-LSA
 graceful-restart partial   # 使能GR Restarter特性,partial参数可选,表示路由器支持部分GR
 
 # 配置参数
 [AR3-ospf-1]graceful-restart ?
  helper-role   Configure helper policy  # 配置Helper端的GR策略
  partial       Partial graceful restart support  # 使路由器支持部分GR（默认支持完全GR）
  period        Time required for the process to complete graceful restart  
                # GR时间,缺省120s,可配置范围为1-180s
  planned-only  Only support planned graceful restart  # 使路由器仅支持有计划GR
            Please press ENTER to execute command 
  
display ospf 1 graceful-restart verbose   # 查看GR详细信息

NSR与NSF

NSR和NSF是用于框式路由设备的技术，都属于高可靠技术

NSF：不间断转发，可以理解为框式设备的GR

NSR：不间断路由，框式设备独有的高可靠机制，通过主控板和备用板之间实时备份，起到在主控板故障时备板快速切换为主板，承担业务转发功能

NSF和NSR互斥，不能同时使用NSF和NSR，只能二选一

NSR原理：

设备使能NSR后，主板将路由信息和转发信息批量备份到备板
批量备份完成后，进入实时备份，主板不间断的将信息备份至备板（参考防火墙双机热备）

备板检测到主板发送故障时，切断主板的接口板报文上送通道，转而使报文上送备板，完成主备倒换

NSR主备倒换的时间足够短，不会和邻居断开连接

如果在批量备份阶段故障，备板可能会由于业务数据不全无法升主，无法完成NSR倒换，设备会整机重启，恢复故障前的状态

配置NSR:

IS-IS高级特性

快速收敛

和OSPF一样，ISIS协议也定义了用于加快收敛速度的特性，包括：增量最短路径优先算法I-SPF、PRC、智能定时器、LSP快速扩散。

同时也支持故障快速恢复的特性，包括ISIS Auto FRR和BFD联动

PRC、智能定时器还有BFD联动在同OSPF一致，ISIS Auto FRR同OSPF中的FRR一致

I-SPF

I-SPF是ISIS有而OSPF没有的特性，I-SPF的作用是：当网络拓扑发生改变时，只对受影响的节点进行路由计算，无需配置默认开启

OSPF无此机制，所以OSPF中拓扑改变后整个区域都要重新进行路由计算

如图，I-SPF只重新计算了从R1-R6这一段的路由

LSP快速扩散

正常情况下，ISIS设备收到新的LSP，会先更新LSDB，然后等待LSP更新定时器超时，设备将LSDB中已更新的LSP扩散出去

LSP快速扩散机制改进了这种做法，开启快速扩散的设备收到新的LSP时，在路由计算之前先将小于指定数量的LSP直接扩展给邻居，加快LSDB同步过程

配置命令：

flash-flood 10 max-timer-interval 100 level-1 
# 开启快速扩散，指定数量为10,定时器为100ms,应用于L1路由

用于可以指定每次扩散的最大数量，这个数量是所有开启ISIS的接口共用的。

如果收到的LSP大于指定数目，则先发送指定数目个LSP，剩下的LSP在路由计算前配置的定时器未超时就立即发送，否则在定时器超时后发送

路由控制

ISIS路由控制包括以下特性：

其中路由优先级、接口开销、等价路由部分和OSPF一致，不做赘述

需要注意在等价路由优选规则中，由于OSPF使用Router-ID标识，而ISIS通过System ID标识，所以优选规则略有区别：

ISIS等价路由的配置命令也和OSPF一致

缺省路由

isis在两种场景中会下发缺省路由

手动下发缺省路由（配置以及作用同OSPF）
在Level-1-2设备上连接有位于其他区域的L2设备时，会向所有L1邻居发送ATT置位为1的路由

L1邻居收到ATT置位为1的路由时，生成一条指向该Level-1-2设备的缺省路由

连接有和L1设备同一区域的L2设备时，ATT不会置位

ATT是否置位，可以由管理员手动配置：

isis 1
 attached-bit advertise always/never   # 控制L1-2设备 ATT置位/ATT不置位
 attached-bit avoid-learning  # 控制L1设备不根据ATT是否置位生成缺省路由

手动下发缺省路由的配置除指定区域等操作外，和OSPF一致

其他特性

ISIS多实例和多进程

ISIS多进程和OSPF多进程类似

对于同一设备的两个ISIS进程，进程之间互不干扰，可以视为两个协议
对于同一链路两端的两个ISIS进程，进程之间可以直接通信

ISIS中，即使链路两端的区域不同，也可以建立邻接关系。除非是区域不同的两个L1设备（不同区域的L1设备之间不能建立ISIS邻居）

多实例是ISIS有而OSPF没有的特性

华为PPT原话是：在同一台路由器上，可以配置多个实例和多个ISIS进程相关联

这个说的太笼统了，所以我在华三的文档中找到了更准确的说法：

在IS-IS视图下开启IS-IS进程的多实例功能，这样就可以在同一个接口下使能多个IS-IS多实例进程。同时，还可以在该接口下使能一个传统IS-IS进程。

简而言之，ISIS之间一个接口绑多个VPN

并且，当ISIS进程绑定的VPN被删除时，进程同步删除

有趣的是，我在华为的文档里没有找到开启多实例的命令，ENSP也不支持在一个接口绑定多个实例

但华三有，大概是华为觉得这个特性没必要做吧：

multi-instance enable iid [iid-value]   # 开启ISIS多实例【华三】

分片与分片扩展

当ISIS发送的PDU很大，ISIS路由器会将该PDU拆分为多个LSP发送，这就是LSP分片

分片由LSP ID中的分片号标识，分片号字段长度1bit，所以一个ISIS进程最多产生256个分片

当PDU非常庞大，256个LSP分片都放不下时，ISIS使用分片扩展功能进一步分片。

分片扩展的原理是在设备上虚拟出多个ISIS系统，这样每个系统都可以发送256个分片。这种方法最多可以虚拟50个系统，也就是说ISIS最多有50*256个分片

命令配置：

ISIS GR

ISIS也有平滑重启机制，并且ISIS GR的思想和OSPF GR的思想一致，但完成方式有所不同，OSPF是新增了9类LSA Grace-LSA实现GR，ISIS是新增了211号TLV Restart TLV和三个定时器实现

211号TLV报文结构如图，Remaining Time表示邻居和重启设备保持邻接关系的最大时间

SA：抑制发布邻接关系位
RA：重启应答位
RR：重启请求位

以主备倒换为例，ISIS重启是GR会经过以下动作：

Restarter 发送包含Restart TLV的IIH报文，其中RR置位。报文发送后Restarter设备开启T1、T2、T3定时器

T1定时器缺省3s，如果T1定时器超时后仍未收到Helper设备RA置位的IIH报文，会重置T1定时器重新发送RR置位的IIH。直到收到消息或T1超时三次。
Helper 收到RR置位的IIH后维持和Restarter的邻接关系，回复RA置位的IIH报文和CSNP和所有LSP
Restarter 收到RA置位IIH，重置T3定时器

T3定时器缺省65535s，表示完成GR的最大时间。T3超时表示GR失败
Restarter 收到CSNP，取消T1定时器，收到所有LSP，取消T2定时器。此时认为GR完成，Restarter向Helper发送Flood LSPs结束GR

T2定时器缺省60s，表示从重启开始到本Level所有设备LSDB同步完成的时间。
Restarter和Helper和更新FIB表‘

配置ISIS GR

isis 1
 graceful-restart  # 使能GR
 graceful-restart no-impact-holdtime  # 配置设备原来的Holdtime值不受GR影响【可选】

缺省时，配置ISIS GR后，如果邻居Holdtime小于60秒，则改为60s，否则保持原Holdtime值

BGP高级特性

正则表达式

正则表达式是按一定模板来匹配字符串的公式，和各大编程语言一样，可以将组成表达式的字符分为两类

普通字符：没有正则含义，表达原本意思的字符
特殊字符：正则语法涉及的字符

除特殊字符之外的字符都是普通字符

例如：^123_；^和_是特殊字符，表达正则的语法，123是普通字符，就只是表达123的意思

特殊字符：

匹配规则和编程语言正则一致

BGP对等体组：Peer Group

原理描述

在大型BGP网络中，往往有众多存在相同配置的BGP对等体，可以把这些对等体创建为一个对等体组。

使用对等体组进行批量配置，以达成简化管理的难度，提高路由发布效率的目的。

在存在RR-路由反射器的场景中应用较多

根据对等体所在的AS是否相同，对等体组可分为三类：

IBGP对等体组：所包括的对等体属于同一个内部AS。
纯EBGP对等体组：所包括的对等体属于同一个外部AS。
混合EBGP对等体组：所包括的对等体属于不同的外部AS。

这三类对等体组原理一致，只是配置命令不同

新加入的对等体如果没有单独的配置，那么将继承对等体组的配置。

加入对等体组之后，如果某个BGP对等体有特殊的配置要求，还可以进行单独的配置，单个对等体的配置将覆盖从对等体组继承的配置。

可向组中加入多个对等体。如果该对等体还未创建，系统会自动在BGP视图下创建该对等体，并设置其AS编号为对等体组的AS编号。

配置命令

配置IBGP对等体组

配置IBGP对等体组不需要指定自治系统号，直接使用本设备的自治系统号。

bgp 200
 group 1 internal  # 创建对等体组 1
 peer 1 connect-interface LoopBack0  # 设置对等体组1的对等体都由环回口0建立邻居关系
 peer 10.1.1.1 group 1  # 将10.1.1.1 加入组
 peer 10.1.2.2 group 1  # 将10.1.2.2 加入组
 
 ipv4-family unicast
  peer 1 enable
  peer 1 reflect-client  # 设置对等体组1中的所有对等体都是RR客户

配置纯EBGP对等体

配置纯EBGP对等体需要给对等体组指定对端AS号

bgp 200
 group 1 external  # 创建对等体组 1
 peer 1 as-number 100  # 指定对等组组1的所有对等体AS为100
 peer 1 connect-interface G 0/0/1  # 设置对等体组1的对等体都由g0/0/1建立邻居关系
 peer 10.1.1.1 group 1  # 将10.1.1.1 加入组
 peer 10.1.2.2 group 1  # 将10.1.2.2 加入组

配置混合EBGP对等体组

配置混合EBGP对等体组时，需要单独指定各对等体的自治系统号。

bgp 200
 group 1 external  # 创建对等体组 1
 peer 1 connect-interface G 0/0/1  # 设置对等体组1的对等体都由g0/0/1建立邻居关系
 peer 10.1.1.1 as 200 # 创建对等体
 peer 10.1.1.1 group 1  # 将10.1.1.1 加入组
 peer 10.1.2.2 as 100 # 创建对等体
 peer 10.1.2.2 group 1  # 将10.1.2.2 加入组

其他配置：

# 配置对等体组描述信息方便网络管理
peer group-name description description-text
# 查看对等体组信息
display bgp group [ group-name ]

路由匹配工具： AS_Path Filter

原理描述

任何协议中，对路由/流量的控制大体都可以分为两步

使用匹配工具抓取路由/流量
使用策略工具处理抓取到的路由/流量

绝大多数工具都只实现了一种功能，只有少数工具兼顾匹配和处理两种功能

AS_Path Filter 就是BGP协议定义的，抓取AS_Path属性的路由匹配工具，除了抓取对象是AS_Path外，和其他匹配工具(ACL、IP-Prefix)没有本质区别

AS_Path Filter中的permit和deny同样可以理解为【抓取】和【不抓取】，路由没有匹配到则：默认【不抓取】

AS_Path Filter抓取的是对应AS_Path的所有路由

AS_Path添加原则：

路由初入AS时，设备检查AS_Path是否有本AS的AS号，无则接收，有则丢弃

路由离开AS时，设备将本AS号添加到AS_Path最前面(最左边)

发送给IBGP不改变AS_Path

所以最右边AS是路由始发位置，越往左距离当前AS越近

BGP路由的AS_Path属性实际上可以看作是一个包含空格的字符串，所以可以通过正则表达式来进行匹配。

配置命令

创建AS_Path Filter过滤器

ip as-path-filter deny_100 deny _100$  # 不抓取AS_Path以100结尾的路由
ip as-path-filter deny_100 permit .*  # 抓取剩下的全部

方案一：在BGP中直接调用AS_Path Filter

bgp 300
 ipv4-family unicast
  peer 10.1.59.5 as-path-filter deny_100 import 
  # 接收从10.1.59.5发来的，AS_Path过滤器deny_100抓取到的入方向路由

方案二：通过路由策略调用

# 用route-policy调用AS_Path Filter
route-policy deny_100 permit node 10 
 if-match as-path-filter deny_100 

# 在BGP中调用route-policy
bgp 300
 ipv4-family unicast
  peer 10.1.59.5 route-policy deny_100 import

路由匹配工具：Community Filter

原理描述

同AS_Path Filter一样，Community Filter同样也是BGP协议下的一种路由匹配工具

AS_Path Filter配合AS_Path属性使用，Community Filter配合Community属性使用

Community Filter有两种类型，并且类似基本ACL编号为2000-2999，高级ACL为3000-3999的编号划分，团体属性过滤器也有编号范围

基本Community Filter：匹配团体号或公认团体属性，编号范围1-99
高级Community Filter：使用正则表达式匹配团体号，编号范围100-199

BGP设备在将带有团体属性的路由发布给其它对等体之前，可以先改变此路由原有的团体属性。

团队属性可以自定义，同时BGP也有一些定义好的公认团体属性

路由器对公认团体属性有默认的处理动作，自定义团体属性的动作需要自己定义

一条路由可以有多个团体属性

公认团体属性：

自定义团体属性：

Community属性是一组4个字节的数值，对应团体属性的定义，RFC1997规定自定义团体属性的前两个字节表示AS号，后两个字节表示基于管理目的设置的标示符，格式为AA：NN。
例如：100:1表示AS号为100，设置的管理标识符为1
也可以直接定义为一个十进制整数【不推荐】

配置命令

要使用团体属性过滤器，前提是路由携带了Community属性。如下图：

给路由设置团体属性

ip ip-prefix 1 index 10 permit 100.100.100.100 32
route-policy 1 permit node 10 
 if-match ip-prefix 1 
 apply community 100:1  # 赋予团体属性100:1
route-policy 1 permit node 20

配置使能将团体属性发布给对等体

默认情况下，Community属性是不会随路由前缀更新给BGP peer的，因此在路由途径的对等体上都需要通过peer advertise-community配置将团体属性发布给对等体的功能。

bgp 100
 ipv4-family unicast
  peer 10.1.18.1 route-policy 1 export  # 使用路由策略
  peer 10.1.18.1 advertise-community  # 使能将团体属性发布给对等体

使用Community Filter抓取打了团体属性的路由并过滤

# 抓取团体属性100:1
ip community-filter 1 permit 100:1

# 使用route-policy处理
route-policy de deny node 10 
 if-match community-filter 1 
route-policy de permit node 20 

# bgp调用route-policy
peer 10.1.59.5 route-policy de import

出口路由过滤器：ORF

原理描述

出口路由过滤器ORF，全称Outbound Route Filters

技术背景：

AS之间往往需要做一些策略，并且在路由出方向做策略比入方向更优。但不同AS往往不能互通，不同AS的网络维护人员也无权维护对端AS设备，这就导致了策略几乎只能做在路由入方向。

本来应该在出口过滤的路由仍然被传入AS内，极大的浪费了带宽和设备资源。频繁联系对端维护人员也不现实

出口路由过滤器ORF可以解决这类问题

基于前缀的ORF能力，能将用户配置的基于前缀的入口策略通过路由刷新报文发送给对端，对端自动将这些策略应用到出口策略，从而在路由发送时对路由进行过滤，避免用户接收大量无用路由，节省资源。

ORF支持路由按需发布，在降低对带宽占用的同时，可以有效减少配置工作。

ORF处理的必须是基于前缀列表（ip-prefix）的过滤策略

配置命令

首先查看对端路由发送，以及本端路由接收情况

对端路由发送

dis bgp routing-table peer 10.1.59.9 advertised-routes

本端路由接收

查看命令：display bgp routing-table peer 10.1.59.5 received-routes

可知对端发送4条，本端接收一条，三条浪费带宽

配置对等体基于前缀列表的路由过滤策略

# 配置前缀列表
ip ip-prefix 1 index 10 permit 200.200.200.200 32
# bgp直接调用前缀列表生成入向过滤策略
bgp 300
 ipv4-family unicast
  peer 10.1.59.5 ip-prefix 1 import

在对等体两端同时开启ORF

本端：
bgp 300
 ipv4-family unicast
 peer 10.1.59.5 capability-advertise orf ip-prefix send  # 本端send(发送)
对端：
bgp 200
 ipv4-family unicast
  peer 10.1.59.9 capability-advertise orf ip-prefix receive  # 对端receive(接收)

查看本端和对端路由发送/接收情况

对端路由发送
本端路由接收

对端发送一条，本端接收一条，没有带宽浪费

BGP安全性

常见的BGP攻击有两种：

建立非法的BGP邻居关系，通告非法路由条目干扰路由表
发送大量的非法BGP报文，路由器收到后上送CPU，导致CPU利用率提高

BGP认证

BGP认证通过建立BGP对等体时验证”密码”，从而预防非法邻居关系建立

分为MD5认证和Keychain认证，并且这两种认证互斥

链路两端要进行相同的配置

MD5认证

通过在建立TCP连接时验证密码，预防非法邻居关系建立

配置简单，但只能针对TCP连接的建立过程进行认证，无法作用于其他过程

最明显的现象就是给已经建立邻居关系的对等体一端设备配置MD5认证，邻居关系不会断开

在配置MD5认证密码时，如果使用simple选项，密码将以明文形式保存在配置文件中，存在安全隐患。建议使用cipher选项，将密码加密保存。MD5认证存在安全风险。

为防止BGP对等体所设置的MD5密码被破解，需要周期性的更新MD5认证密码。

配置：

bgp 100
 peer 10.1.18.1 as-number 200 
 peer 10.1.18.1 password cipher [密码]

Keychain认证

Keychain认证相对MD5认证安全性更高，但配置也更加麻烦，适用于对安全要求较高的网络

BGP对等体两端必须都配置针对使用TCP连接的应用程序的Keychain认证，且配置的Keychain必须使用相同的加密算法和密码，才能正常建立TCP连接，交互BGP消息。

Keychain认证推荐使用SHA256和HMAC-SHA256加密算法。

配置：

配置keychain认证需要提前配置keychain

bgp 100
 peer 10.1.18.1 as-number 200 
 peer 10.1.18.1 keychain [keychainName]

其他命令：

display bgp peer verbose  # 查看对等体详细信息

BGP GTSM(通用TTL安全保护机制)

争对伪造非法BGP报文的攻击，由于TTL机制，无论报文如何逼真，TTL值一定有问题

比如路由器和邻居直连，收到的TTL应为255，但攻击者不和BGP设备直连，发送给设备的TTL就会小于255

GTSM功能通过检测IP报文头中的TTL值。根据实际组网的需要，对于不符合TTL值范围的报文，GTSM可以设置为通过或丢弃。

TTL计算公式：[255-hops+1 : 255]

注：从环回口始发的报文到设备时，TTL也会减一

配置：

bgp 300
 peer 10.1.59.5 valid-ttl-hops 255  # 设置有效TTL最小255

其他配置：

gtsm default-action { drop | pass }  # 设置未匹配GTSM策略的报文的缺省动作
gtsm log drop-packet all  # 打开单板的LOG信息的开关，在单板GTSM丢弃报文时记录LOG信息

缺省情况下，未匹配GTSM策略的报文可以通过过滤。

缺省情况下，不记录单板的LOG信息

这两条命令在模拟器上敲不上去

RR组网

为了增加网络可靠性，有时需要在一个网络中部署多个RR，在这类场景下，可以将RR的组网方式分为两类

单集群RR组网

也叫备份RR组网

如图，两个RR在一个集群内，配置了相同的簇ID(Cluster ID)

缺省情况下，每个路由反射器使用自己的Router ID作为集群ID(Cluster ID)。

Client1、Client2和RR1、RR2都建立邻居关系，RR1、RR2之间建立普通IBGP关系（非客户）

RR反射原则：

从客户学到的路由，反射给所有对等体（客户和非客户）

从非客户学到的路由，反射给所有客户

对于Client而言，会收到两个RR反射的路由，形成冗余链路
对于RR而言，两个RR都独立工作，由于具有相同簇ID，根据RR反射器防环规则，两个RR都会丢掉对方发给自己的路由

 ipv4-family unicast
  #  设置RR1簇ID为10.1.4.4
  reflector cluster-id 10.1.4.4

单集群RR组网问题

如图，AS内多个RR单集群组网，如果R4和反射器R3之间的邻居关系断开（配置错误、网络波动等原因）

此时RR1仍然将R4的路由反射到R1，而RR2由于和R4没有邻居关系，不会反射R4的路由(单集群中两个RR的Cluster ID一致，RR2不会接收RR1反射的路由)

最终导致虽然有两个RR，但链路故障后失去的冗余链路（R1到R4此时只有RR1反射的路由）

想要解决这个问题，就需要配置簇ID不同的多集群组网

此时R4和RR2断开，但由于RR1和RR2之间有不同的簇ID，RR1将从R4学到的路由同时反射给R1和RR2

RR2和R1仍然存在邻居关系，所以将路由反射给R1

此时R1到R4有从RR1学到的和RR2学到的2条路由，冗余仍然存在

多集群RR组网

综上，在比较复杂的网络中，多集群RR组网比单集群更优，多集群组网又分为两种方案

多集群全互联组网

如图，每个RR都和本集群的Client建立IBGP对等体，同时RR之间建立普通IBGP对等体(非客户)关系并形成全互联

此时图中4个RR都属于同级关系，除非链路全断，否则一直存在三个链路的冗余

多集群分级组网

如图，将核心设备分入一个簇，其他设备分入不同簇，就是多集群下的分级组网

以核心的RR为一级反射，使客户端路由互通

同时一级RR的客户端也是二级反射簇的RR，负责本客户端集群的路由反射

RR组网示例

上图拓扑可以分为两块

RR1单独维护AR1-4的路由
RR2和RR3共同维护AR1-4的路由

所以RR2和RR3肯定要建立对等体关系，由于两个RR的客户没有重复，所以划入一个簇

RR1可以选择和RR2、RR3一个簇形成全互联单集群备份组网，但由于单集群组网局限性，这里不优先考虑

为避免局限性，将RR1划入一个单独的簇，和RR2、RR3形成全互联的多集群组网

可以简单写为如下逻辑图：

配置命令：

各Client已经和对应RR建立了邻居关系

RR1

bgp 200
 #  将client加入一组
 group client_peer internal
 peer client_peer connect-interface LoopBack0
 peer 10.1.1.1 group client_peer 
 peer 10.1.2.2 group client_peer 
 peer 10.1.3.3 group client_peer 
 peer 10.1.5.5 group client_peer 
 #  将rr加入一组
 group rr internal
 peer rr connect-interface LoopBack0
 peer 10.1.6.6 group rr 
 peer 10.1.7.7 group rr 
 
 ipv4-family unicast
  #  设置RR1簇ID为10.1.4.4
  reflector cluster-id 10.1.4.4
  #  将client设为RR1客户
  peer client_peer reflect-client

RR2

bgp 200
 group client_peer internal
 peer client_peer connect-interface LoopBack0
 peer 10.1.1.1 group client_peer 
 peer 10.1.2.2 group client_peer 
 peer 10.1.3.3 group client_peer 
 peer 10.1.7.7 group client_peer 
 group rr internal
 peer rr connect-interface LoopBack0
 peer 10.1.4.4 group rr 
 
 ipv4-family unicast
  reflector cluster-id 10.1.67.67
  peer client_peer reflect-client

RR3

bgp 200
 group client_peer internal
 peer client_peer connect-interface LoopBack0
 peer 10.1.5.5 group client_peer 
 peer 10.1.6.6 group client_peer 
 group rr internal
 peer rr connect-interface LoopBack0
 peer 10.1.4.4 group rr 
 
 ipv4-family unicast
  reflector cluster-id 10.1.67.67
  peer client_peer reflect-client

此时查看AR5路由表

可以看到每个路由都有两个冗余

4字节AS号

随着网络规模的扩大，2字节的AS号已经濒临枯竭。所以将AS号从2字节的65536个扩展到了4字节，且支持4字节AS的设备能够和仅支持2字节的设备兼容

4字节AS号有两种格式：

整数格式：像2字节一样直接写，比如131075
点分格式：由于4字节AS号很多，直接写不方便，所以用x.y的形式表示

点分格式与整数格式的换算关系：x.y = x * 65536 + y；也就是说，每1.0=65535

BGP使用OPEN报文交互AS号，但OPEN报文的消息头是固定的，为了表示4字节AS号，BGP将原AS号固定位23456，同时将4字节AS写入Options字段中

当具有处理4字节AS的设备读到AS字段为23456时，自动从Options字段读取真正的AS(4字节AS)号

如果BGP网络中同时存在支持4字节和仅支持2字节AS的设备，那么支持4字节设备使用2字节AS号23456和仅支持2字节的设备建立邻居关系

对于支持4字节AS号的设备，Update消息中会携带AS4消息，而仅支持2字节的设备处理AS消息

当4字节设备从2字节设备收到带有AS4_path属性的Update报文时，会根据AS4_Path属性和AS_Path属性重新计算出真正的AS_Path属性

undo peer 10.1.12.1 capability-advertise 4-byte-as  # 关闭和对等体10.1.12.1交互4字节AS的功能

：想用ensp模拟4字节设备和2字节设备的交互，但邻居建立不起来

MPLS L3VPN跨域

当企业规模不断扩大，不同地点的企业站点可能属于不同的AS，对此就需要VPN跨域技术，RFC基于IP阶段学习的MPLS VPN提出了三种跨域解决方案

跨域场景中VPN工作原理不变，但由于跨越了AS，所以有以下问题：

AS之间不会运行LDP协议，因此AS之间无法建立外层标签转发隧道
PE之间不会运行IGP协议，因此跨AS的PE之间无法直接建立BGP邻居关系，所以无法传递VPNv4路由

三种跨域方案本质上都是在解决这两个问题，即建立跨AS标签转发隧道和跨AS学习对端PE路由

三种方案代表三种不同的解决思路，每种方案都是对前者的优化。基于前者，优于前者。

三种方案没有优劣之分，只是说是提出的顺序问题，A方案只是解决跨域的可行方案，B方案是对A的升级，C是对B的再升级。

疑惑C最好用为什么还有A、B方案就像是在疑惑小米13配置这么高为什么还会有小米11一样。没有为什么，只是提出的时间不同

Option A方案

OptionA方案的做法是ASBR之间互相将对方看做CE，通过EBGP对等体传递IPv4路由完成跨域

控制平面路由交互流程图：

由于是将对端ASBR当做CE，所以在方案A中，ASBR之间用多个物理接口/子接口互联，每个接口绑定一个VPN实例，但不需要启动MPLS

方案A配置简单，但对ASBR-PE的压力极大（ASBR-PE需要维护AS中所有VPN实例的路由表），并且可扩展性差，一般不使用

转发层面标签变化：

配置示例：

A方案网络拓扑：

# 基础ospf 配置/ MPLS 配置略
# CE1、CE2正常与PE设备建立ospf邻居

# PE1配置
# 创建vpn
ip vpn-instance vpn
 ipv4-family
  route-distinguisher 100:1
  vpn-target 1:1 export-extcommunity
  vpn-target 1:1 import-extcommunity
# 将vpn绑定到接口
interface GigabitEthernet0/0/0
 ip binding vpn-instance vpn
 ip address 192.168.12.2 255.255.255.0 
# 开启ospf与CE互通，绑定vpn
ospf 100 vpn-instance vpn
 import-route bgp  # 将学到的BGP路由引入ospf 100
 area 0.0.0.0 
  network 192.168.12.0 0.0.0.255 
# 配置BGP,和ASBR1建立VPNv4邻居关系
bgp 100
 peer 3.3.3.3 as-number 100 
 peer 3.3.3.3 connect-interface LoopBack0
 ipv4-family vpnv4
  policy vpn-target
  peer 3.3.3.3 enable
 ipv4-family vpn-instance vpn 
  import-route ospf 100

# ASBR1配置
# 创建VPN
ip vpn-instance vpn
 ipv4-family
  route-distinguisher 300:1
  vpn-target 1:1 export-extcommunity
  vpn-target 1:1 import-extcommunity
# 将VPN绑定到子接口/物理接口
interface GigabitEthernet0/0/1.1  # 这里绑定子接口
 dot1q termination vid 1  # 将子接口划入vlan1
 ip binding vpn-instance vpn
 ip address 10.1.45.4 255.255.255.0 
 arp broadcast enable  # 开启arp广播 （开启子接口）
# 配置BGP,和PE1建立VPNv4邻居，和ASBR2建立IPv4 VPN邻居
bgp 100
 peer 1.1.1.1 as-number 100 
 peer 1.1.1.1 connect-interface LoopBack0
 ipv4-family vpnv4
  peer 1.1.1.1 enable  # 建立VPNv4邻居
 ipv4-family vpn-instance vpn 
  peer 10.1.45.5 as-number 200  # 建立IPv4邻居

bgp 200的配置和bgp 100一致

Option B方案

Option B方案中，路由转发到ASBR-PE时，ASBR-PE通过MP-BGP给路由主动打上外层标签，然后通过MP-BGP分配的标签将路由以MPLS的形式转发。

外层标签的本质就是下一跳

所以Option B方案无需在ABSR创建VPN实例，也无需绑定任何接口，但ASBR仍然维护AS内所有PE的VPNv4路由。相对来说，对ASBR的压力比之A方案小很多

由于B方案ASBR仍然维护大量的VPNv4路由，所以ASBR一般不再负责公网IPv4业务转发

B方案分带RR和不带RR两种场景：

不带RR场景

控制层面路由交互流程：

路由到达ASBR后会被ASBR重新分配内层标签（MP-BGP分配，无需配置，VPNv4路由下一跳发生变化自动重分配）

为了使携带MP-BGP内层标签的路由通过MPLS转发，两个ASBR之间的链路上需要使能MPLS

转发平面流程：

命令配置：

网络拓扑：

# PE1/PE2配置和方案A一样，主要是ASBR配置有所区别
# ASBR不再创建VPN实例

# ASBR配置
bgp 100
 peer 1.1.1.1 as-number 100 
 peer 1.1.1.1 connect-interface LoopBack0
 peer 10.1.45.5 as-number 200 
 ipv4-family vpnv4
  undo policy vpn-target  # 关闭RT检查
  apply-label per-nexthop  # 给下一跳相同的路由分配相同的标签
  peer 1.1.1.1 enable
  peer 10.1.45.5 enable

带RR场景

控制平面路由交互流程：

MPLS VPN跨域时RR一般都使用旁挂组网，这是为了减少RR的压力，使RR只承担整个AS的路由反射工作，而不承担流量转发工作

B方案带RR场景转发平面原理和不带RR一致

带RR配置只是比不带RR多了一个RR反射器反射VPNv4路由，其他没有区别。

Option C方案

即使方案B已经在方案A的基础上做了非常大的改进，但在AS中站点很多时ASBR设备要保存大量的VPNv4路由，压力仍然很大

Option C方案通过让用户各自的PE设备维护各自的VPNv4路由表，并直接和对端PE建立VPNv4邻居关系。使得ASBR不在需要维护VPNv4路由，彻底解放了ASBR的压力

缺点是PE和PE直接直接建立VPNv4邻居，链接多，管理难度大

C方案的原理是路由到ASBR后在VPNv4路由内层标签的基础上再用BGP打一层标签，从而使得设备可以根据这层标签找到对端PE

而控制层面使用IPv4簇和VPNv4簇的分层，首先通过BGP建立IPv4邻居关系并将本AS内PE的路由通告给其他AS。然后其他AS通过IPv4簇通告的路由，直接与本AS的PE建立VPNv4邻居关系。

想要正确理解路由平面和转发平面的关系，就要明白一句话：

下一跳是路由发送者，路由携带的下一跳是路由发送者，流量转发的下一跳也是路由发送者

这两个概念在方向上是相反的，但值是相同的。

流量不必多说，下一跳不可达报文自然不能继续转发。

而对于路由，路由器收到一条路由后，会检查路由下一跳是否可达（能不能到达路由发送者）

可达则将这条路由写入路由表，不可达则不会写入路由表

C方案有两种解决方式，两种方式的ASBR之间都是通过BGP再打一层标签实现转发

方式一：

控制平面流程图：

路由到达ASBR1，由ASBR1打上BGP标签通过BGP转发到ASBR2

ASBR2重新分配BGP标签，并打上LDP标签，以三层标签的形式转发到PE2

为什么要以三层标签的方式转发到PE2?

如果ASBR2不重新分配MP-BGP标签。路由到达ASBR2的标签是BGP发布的，LDP中没有对应的入标签与之对应，所以不能通过LDP打标签继续传递。

并且ASBR2不存在VPNv4地址簇，也就不维护VPNv4路由表，所以弹出BGP标签后，也无法通过VPNv4进行路由传递。

基于此原因，C方案方式一的做法是ASBR2建立和PE2的BGP标签转发，交换路由中携带BGP标签，使ASBR知道出标签应转发给PE2，而LDP有去往PE2的标签，所以就变成了三层标签转发

PE1发送的路由在对端AS通过三层标签转发，PE2发送的路由在本端AS也通过三层标签转发。如此一来，对于转发平面，整理业务流量都是通过三层标签进行通信

转发平面流程图：

C方案的方式一和方式二都分带RR和不带RR两种配置

不带RR配置除了需要建立IPv4邻居外，只有ASBR和方案B配置有区别（多两个策略）

所以C方案配置直接以带RR展示

C方案方式一带RR配置：

网络拓扑：

建立IPv4邻居关系以及标签转发

# PE1配置
bgp 100
 peer 7.7.7.7 as-number 100 
 peer 7.7.7.7 connect-interface LoopBack0
 ipv4-family unicast  # 方案C基于IPv4和VPNv4传递路由，所以不能取消ipv4邻居
  peer 7.7.7.7 enable
  peer 7.7.7.7 label-route-capability  # 建立标签转发

# RR1配置
bgp 100
 group ipv4 internal
 peer ipv4 connect-interface LoopBack0
 peer 1.1.1.1 as-number 100 
 peer 1.1.1.1 group ipv4 
 peer 3.3.3.3 as-number 100 
 peer 3.3.3.3 group ipv4 
 ipv4-family unicast  # 建立IPv4标签转发以及反射
  peer ipv4 enable
  peer ipv4 reflect-client
  peer ipv4 label-route-capability
  peer 1.1.1.1 enable
  peer 1.1.1.1 group ipv4 
  peer 3.3.3.3 enable
  peer 3.3.3.3 group ipv4 

# ASBR1配置
## 收到不存在bgp标签的路由打上标签
route-policy policy1 permit node 10 
 apply mpls-label
route-policy policy1 permit node 20 
## 对已经存在标签的路由更新标签
route-policy policy2 permit node 10 
 if-match mpls-label 
 apply mpls-label
route-policy policy2 permit node 20 

bgp 100
 peer 7.7.7.7 as-number 100 
 peer 7.7.7.7 connect-interface LoopBack0
 peer 10.1.45.5 as-number 200 
 ipv4-family unicast
  network 1.1.1.1 255.255.255.255   # 宣告PE路由到对端AS
  network 7.7.7.7 255.255.255.255   # 宣告RR路由到对端AS
  peer 7.7.7.7 enable
  peer 7.7.7.7 route-policy policy2 export  # 应用策略建立标签转发
  peer 7.7.7.7 next-hop-local # 基于ipv4特性修改IBGP下一跳为本地
  peer 7.7.7.7 label-route-capability  # 使能bgp标签
  peer 10.1.45.5 enable
  peer 10.1.45.5 route-policy policy1 export
  peer 10.1.45.5 label-route-capability
 
interface GigabitEthernet0/0/1
 mpls  # 在和对端AS直连的接口上使能mpls
mpls
 lsp-trigger bgp-label-route  # 使能mpls给携带BGP标签的路由分配标签

建立BGP IPV4标签转发需要注意以下问题：

BGP IPV4路由传递的特点是：
- 发往EBGP的路由自动改变下一跳为自身
- 发往IBGP的路由下一跳不变
所以为了防止RR收到的路由下一跳不为本端ASBR而是对端ASBR，需要配置next-hop-local
MPLS默认只会给32位主机路由分配标签，为了建立对端AS路由的标签转发隧道，需要更改为bgp-label-route为携带BGP标签的路由分配标签
AS需要将自身的建立VPNv4邻居的路由传递到对端AS，在RR承担流量转发工作时，可以只传递RR的路由而不传递PE。但承担VPNv4路由转发的同时再承担流量转发对RR压力非常大，不建议这么做。

所以RR一般只承担路由转发工具，此时路由下一跳直接指向PE，为了使下一跳可达，需要向对端通过PE的路由

总结：RR承担流量转发只需要通告RR的路由，RR不承担流量转发需要通告RR的路由和PE的路由

建立VPNv4邻居关系

# PE1
bgp 100
 peer 7.7.7.7 as-number 100 
 peer 7.7.7.7 connect-interface LoopBack0
 ipv4-family vpnv4
  policy vpn-target
  peer 7.7.7.7 enable
 ipv4-family vpn-instance vpn 
  import-route ospf 100
ospf 100 vpn-instance vpn
 import-route bgp  # 在ospf 100中引入BGP路由

# RR1
bgp 100
 peer 8.8.8.8 as-number 200 
 peer 8.8.8.8 ebgp-max-hop 255 
 peer 8.8.8.8 connect-interface LoopBack0
 group ipv4 internal
 peer ipv4 connect-interface LoopBack0
 peer 1.1.1.1 as-number 100 
 peer 1.1.1.1 group ipv4 
 ipv4-family unicast
  undo peer 8.8.8.8 enable  # 去使能与对端AS中RR的IPv4邻居
 ipv4-family vpnv4
  undo policy vpn-target  # 关闭RT检查
  peer 1.1.1.1 enable
  peer 1.1.1.1 next-hop-invariable  # 设置RR反射路由不改变下一跳
  peer 8.8.8.8 enable
  peer 8.8.8.8 next-hop-invariable

BGP VPNv4路由传递需要注意以下几点：

华为设备会自动为对等体使能Pv4关系（华三设备不会）。由于方案C使能IPv4传递标签，如果不关闭两个AS中RR的IPv4关系，就会形成RR1-RR2-ASBR2-ASBR1的路由环路以及次优路径

所以需要配置undo peer 8.8.8.8 enable 去使能与对端AS中RR的IPv4邻居
BGP VPNv4路由传递的特点是：路由每传递一次，下一跳自动变为当前设备

这个机制在MPLS VPN中非常方便，但带RR跨域中就很麻烦：会使下一跳为RR。所以需要在RR中配置next-hop-invariable ，使RR反射路由的同时不改变下一跳
RR没有VPN实例，根据RT的规则，RR无法接收VPNv4路由（参考方案B）

为了使RR能够接收并反射VPNv4路由，需要配置undo policy vpn-target关闭RR VPNv4簇中的RT值检查

方式二：

方式二和方式一都存在BGP标签到达对端ASBR后，无法通过LDP标签转发的问题。方式一的解决方法是剩下的路用BGP指明。所以ASBR重新分配MP-BGP标签。

方式二的做法是将BGP路由引入对端AS的IGP。MPLS LDP的作用是给IGP路由分配标签，所以MPLS会为引入的本端PE路由生成新的标签转发表项。

生成指向本端PE的LDP标签转发表项（下一跳是本端PE）

VPNv4路由在对端ASBR弹出BGP标签后，由LDP接手转发到对端PE。

控制平面交互示意图：

转发平面示意图：

C方案方式二带RR配置：

方式二除了AS内不建立BGP标签转发，改为将BGP引入IGP使得LDP协议为对端AS路由建立标签隧道外，和方式一的配置没有区别

# ASBR1配置
ospf 10 
 import-route bgp  # 将BGP路由引入IGP
mpls
 lsp-trigger bgp-label-route  # 配置MPLS为携带BGP标签的路由分配标签
bgp 100
 peer 7.7.7.7 as-number 100 
 peer 7.7.7.7 connect-interface LoopBack0
 peer 10.1.45.5 as-number 200 
 ipv4-family unicast
  network 1.1.1.1 255.255.255.255 
  network 7.7.7.7 255.255.255.255 
  # ASBR与RR不在建立BGP标签隧道
  peer 7.7.7.7 enable
  peer 7.7.7.7 next-hop-local
  # 与对端ASBR仍然建立BGP标签隧道
  peer 10.1.45.5 enable
  peer 10.1.45.5 route-policy policy1 export
  peer 10.1.45.5 label-route-capability

其他设备均取消BGP标签转发即可

不带RR配置只是没有RR以及RR产生的环路和通告问题，其他配置都一样

EVPN VPLS

EVPN概述

EVPN是Ethernet VPN的简称，是下一代全业务承载的VPN解决方案。

EVPN统一了其他VPN的控制层，利用BGP扩展报文传递二层以及三层的路由信息，实现转控分离

提出EVPN的初衷是为了解决传统L2VPN的不足，比如不支持负载分担，网络资源消耗高等问题。但在后续的使用中发现EVPN可以应用于所有VPN控制层，成为了下一代全业务承载的VPN解决方案。

由于三层VPN普遍比较成熟(比如MPLS VPN)，EVPN并不常用于三层VPN。更多的是作为二层VPN控制层在网络中部署。

目前常用的EVPN解决方案有EVPN VPLS和EVPN VXALN两种，对于EVPN原理的学习，我是从EVPN VPLS开始

EVPN 基本原理

EVPN是通过扩展MP-BGP实现的，对于控制层面，使用MP-BGP协议交互路由信息。转发平面则因协议而异，EVPN VPLS通过MPLS实现转发

EVPN术语：

ES：Ethernet Segment 以太网段，指用户站点连接到PE设备的一组以太网链路

连接同一CE的不同PE所在链路也是属于同一ES【可以理解为一个CE就是一个ES，包括CE连接PE的链路】
在VPLS中，连接CE和PE的一条链路称为AC

ESI：Ethernet Segment Identifier 以太网段标识，唯一标识一个ES

同一ES双归中的所有evpn实例ESI相同
双归双活：一个CE连接两个PE，即可组成双归双活
- 双归：CE所连接的两个PE都会发送流量给CE，称为双归
- 双活：CE和两个PE负载分担，CE会将流量发送给任一PE，称为双活
如果CE只将流量发送给其中一个PE，但两个PE都会给CE发送流量，称为双归单活。其他同理
ESI格式为:xxxx.xxxx.xxxx.xxxx.xxxx，是五组16bit的16进制字符串（共10bytes），第一组16进制在NE设备中必须为0
ESI全网（整个EVPN网络）唯一

EVI：EVPN instance EVPN实例，代表一个EVPN实例

RD：EVI唯一标识，用于区分EVI，一般每个PE设备上的EVPN实例都有一个单独的RD

RT：同MPLS VPN，用于控制路由引入

DF：Designated Forwarder 指定转发路由器，用于EVPN多归场景中只转发一份BUM到CE

ESI Label：EVPN Type 1携带的扩展团体属性。用于多归场景中实现快速收敛和水平分割

BUM Label：由Type 3路由携带，用于转发BUM流量

BUM（Broadcast、Unicast、Multicast）广播、未知单播、组播的统称

单播 Label：由Type 2路由携带，用于转发已知单播流量

MAC-VRF：EVI的MAC地址表

就像L3VPN中每个VPN实例都会生成一张单独的路由表，L2VPN也会给每个实例生成一张单独的MAC地址表

EVPN路由

EVPN网络构建过程主要通过MP-BGP扩展的EVPN NLRI实现，EVPN NLRI的AFI为25，SAFI为70

EVPN NLRI定义了8种用于EVPN网络构建的路由（EVPN 路由），其中在L2VPN中只使用前四种

其中Type 1-4（前四种路由）是组网EVPN网络的基础，Type 5用于L3VPN，Type 6-8用于组播

在EVPN VPLS中不涉及后四种，后四种NE系列设备文档有说明

四类路由名称以及作用如下：

EVPN通过这四类路由完成整个的工作流程，拆分来看分为两步，建立三个表

启动阶段：
1. 交互Type 3路由建立BUM流量转发表
  
  BUM：广播、组播和未知单播流量的统称。又称多播流量
2. 交互Type 4路由完成ES发现和DF选举
  
  只有在多归场景中才会进行DF选举
3. 交互Type 1的两类路由交互ESI标签，从而在多归场景中实现水平分割、别名功能
流量转发：

CE发送流量到PE，PE通过Type 2路由通告收到报文的源MAC地址和标签信息，后续根据该标签执行单播转发

EVPN维护的三张表分别是：

MAC-VRF：虚拟MAC地址表，每个EVI都有一张独立的MAC-VRF，记录已知单播流量的标签、下一跳和ESI。和MAC地址表一样，表项由流量刺激形成
BUM流量转发表：指导广播、组播和未知单播报文的转发，由Type 3路由在EVPN网络中交互形成
ES成员信息表：用于记录用户接入PE信息，通过Type 1路由生成

EVPN路由交互——启动阶段

以下配置以VLAN Based服务模式为例

实验拓扑：

激活EVPN

1、在PE上创建EVI并配置RD、RT后。PE本地自动激活EVPN，并产生一个MAC-VRF表，此时MAC-VRF为空

# 指定本端EVPN源地址
evpn source-address 1.1.1.1 

# 创建bd-mode模式【广播域模式】的evpn实例并配置RD\RT值
evpn vpn-instance evpn bd-mode
 route-distinguisher 100:1
 vpn-target 1:1 export-extcommunity
 vpn-target 1:1 import-extcommunity

dis evpn mac routing-table evpn-instance [evpn]   # 查看evpn实例的mac-vrf表

Type 3路由交互

2、激活EVPN的PE设备之间建立BGP EVPN邻居关系后，交互Type 3路由，建立BUM流量转发表

如图，通过Type 3路由携带的RD以及Label，将收到的RT值允许的EVPN关系写入路由表，以此建立BUM流量转发表，标识去往PE要打的标签

由于不接受RT不被允许的路由，所以BUM转发表只有去往存在import RT的EVPN所在的PE

Type 4路由交互

3、将EVI应用到具体ES，PE之间发送Type 4路由选举DF，并建立ES成员信息表。

为了避免发生环路，EVPN网络只允许DF将BUM流量发送到CE。

在CE设备和PE设备聚合口UP时，所有PE设备都会通告Tpye 4路由进行DF选举，单归设备自动成为DF(也发送Type 4路由)

多归PE收到Type 4路由后，经过一系列哈希运算选举出DF

CE1:
# 基本配置
vlan batch 2
interface Vlanif2
 ip address 10.1.2.2 255.255.255.0
# 配置聚合口
interface Eth-Trunk10
 port link-type trunk
 port trunk allow-pass vlan 2
 mode lacp-static

dis evpn vpn-instance name evpn df result   # 查看DF选举结果
dis bgp evpn all routing-table es-route   # 查看bgp四类路由表

Type 4报文：

BGP Type 4路由表

Type 1路由交互

4、流量转发表建立成功，所有PE互相通告Type 1路由

Type 1路由分为两种，用途不用

Peer EVI：用于别名机制并通告具体EVPN实例/广播域的MPLS Label

别名：向其他PE通告本端可达。

EVPN网络中PE收到MAC/IP通告（Type2）会认为对端可达并按照Type 2路由生成的MAC-VRF表项发送数据。

但并非每个PE都会收到CE的MAC(CE没有向PE发送任何数据)从而产生Type 2路由，所以通过EVPN网络建立完毕后向对端发送Peer EVI报文，使对端即使没有收到Type 2，仍然认为本端可达

抓包发现所有的PE只要配置ESI并把实例绑定到具体接口就会通告Peer EVI，并且和顺序无关（没有交互Type 4也会发送Peer EVI）

以上为对华为文档的总结，但我认为多少是晦涩了点

经过研究之后，我认为Peer EVI的作用是顶替了L3VPN MPLS VPN中MP-BGP对内层标签的通告。

一个ES中可以存在多个EVI，而无论是报文根据MAC-VRF的单播转发还是根据BUM的抓发，都只支持转发到PE，而不能转发到具体的EVPN实例。

而通告Peer EVI通告一个标识具体EVPN实例的内层标签，就可以像三层MPLS VPN一样，先通告MPLS(MAC-VRF)转发到PE，再通过EVI标签转发到具体实例中

文档原文：Per EVI路由上MPLS Label为EVPN单播流量负载分担转发时使用的MPLS标签。

# 多归场景中同一ES的PE配置
lacp e-trunk system-id 0000-1111-0000  # 指定lacp systemid 
lacp e-trunk priority 1  # 指定本设备lacp优先级

# 进入聚合口（VLAN Based服务模式必须绑定聚合口）
interface Eth-Trunk10
 mode lacp-static
 e-trunk 1  # 多归场景中绑定e-trunk聚合组
 e-trunk mode force-master  # 多归场景中配置本端为主设备（多主配置中多归的设备都需要进行配置）
 esi 0000.1111.1111.1111.1111  # 手动设定ESI
 trunkport ether 1/0/0  # 绑定物理接口到聚合口

# 配置聚合口二层子接口（NE设备物理口配了lacp就绑不了evpn，也配不了二层。所以开个子接口接收二层数据）
interface Eth-Trunk10.1 mode l2  # 子接口必须为L2模式
 encapsulation dot1q vid 2  # 允许接收vlan 2的数据
 rewrite pop single  # 剥离收到的数据最外层vlan tag
 bridge-domain 10  # 绑定bd域 10

Peer EVI报文抓包：

Peer ES：用于快速收敛、多归场景中水平分割，通告指向ES的ESI Label报文

水平分割：

ESI Label是bgp中Peer ES的扩展团体属性。流量转发时，对于收到ESI Label标识同一ES的流量会被PE丢弃（多归防环）

对于单播报文，不存在报文重复或者环路，只有BUM报文转发时才有环路的可能

为了验证广播报文发现时发送PE是只给同一ES的PE带上ESI Label发送还是一视同仁全部都带，我用LSW ping了广播地址保证每个报文都是广播，得到以下结果：

结论：

发送BUM报文时，内层标签为Peer ES通告的ESI Label，外层为MPLS Label（BUM转发表标签）

对端PE检查ESI Label判断发送报文的PE是否和自己同属一个ES(标签对应的ESI和本端ESI相同即为同属一个ES)

同属一个ES则丢弃（水平分割防环）

不同属一个ES，但本设备非DF，丢弃（防CE收到重复报文）

不同属一个ES，且本设备为DF，接收并发送至CE

发送单播报文时，内层标签为Peer EVI通告的MPLS Label，外层为MPLS Label(MAC-VRF指导)

对端收到后，根据内层标签发送至对应EVPN实例

Peer ES同Type 4路由一样，在PE和CE相连的链路UP之后，所有PE设备互相通告Peer ES报文

在步奏3中配置CE和PE交互后就会发送Peer ES报文用于水平分割，所以配置略

在NE设备中，Peer ES的MPLS Label字段取值为ESI标签值

ESI MPLS Label 和MPLS Label是两个概念，前者在扩展团体属性中，后者在NLRI中

文档的

配置peer esad-route-compatible enable后，MPLS Label字段改为全0

快速收敛：
当PE检查到CE故障时，为所有ES通告Peer ES报文。其他PE收到后会撤销对应的MAC表项，从而实现快速收敛

dis bgp evpn all routing-table ad-route   # 查看Type 1路由

EVPN流量转发——转发阶段

EVPN流量转发分为单播转发和BUM转发（非单播转发）。单播转发由流量刺激形成的MAC-VRF指导，广播转发由Type 3路由形成BUM转发表(EVPN三类路由表)指导

以一次ARP为例，流量转发阶段会经过如下流程

1、CE发送ARP数据到PE，PE根据报文源MAC地址生成Type 2路由，携带PE分配的标签通告其他PE

Type 2报文：

其他PE收到Type 2路由后，将路由写入对应实例的MAC-VRF表中

在存在多归的EVPN网络中，如果DF收到非DF发送的Type 2路由，则会同步发送一条以自己为下一跳的Type 2路由。这样就形成了多归的负载分担

2、PE发送Type2路由后，控制平面动作完毕，执行数据平面动作（转发ARP广播）

控制平面执行完毕后，PE根据BUM转发表，向每个Import RT允许接收本端数据的PE发送一份ARP请求（有几个PE就发送几份）

对端PE收到后，根据报文携带的MPLS 内层标签转发到对应EVPN实例

在多归场景中，只有DF收到才会向EVPN转发，非DF丢弃BUM报文

3、对端CE收到ARP请求，回复ARP响应到对端PE

对端PE收到对端CE发来的ARP响应后，根据报文中源MAC生成Type 2路由通告给其他PE。

然后查MAC-VRF报文转发到本端PE，由本端PE根据内层MPLS Label转发到CE

后续单播报文均通过MAC-VRF转发

Type 5路由——引入外部路由信息

Type 5路由：IP前缀通告。用于EVPN L3VPN的场景或者将IP路由引入L2VPN网络，实现EVPN和外部网络互通

EVPN报文详解：

以上是EVPN的路由交互和流量转发过程，以及各类路由在这些过程中起到的作用。

下面是对各类路由报文字段的详细解析

Type 1：以太网自动发现路由

以太网自动发现路由：Ethernet Auto-Discovery Route，简称A-D Route，在Type3路由交互完毕，PE和CE直接的链路UP后发送。

A-D Route根据作用的不同又分为两类：

Peer EVI A-D Route：主要用于别名机制
Peer ES A-D Route：用于快速收敛、冗余模式和水平分割

所有PE都会发送这两种A-D Route报文

报文格式：

Route Distinguisher：即RD，在Peer ES和Peer EVI中，这个字段的取值不同

Peer ES：由PE中管理员指定的源IP地址+0组合而成，例如1.1.1.1:0
```
evpn source 1.1.1.1  # 指定evpn地址为1.1.1.1
```
Peer EVI：EVPN实例的RD值

Ethernet Segment Identifier：PE所连接的ES的ESI

Ethernet Tag ID：以太网标签标识，在Peer ES和Peer EVI中取值不同

Peer ES：全F
Peer EVI：在EVPN VPLS中标识一个ES下的不同的子广播域，全0表示EVI中只有一个广播域。在EVPN VPWS场景中取值为本端Service ID

MPLS Label：

Peer ES：全0

在NE设备中，Peer ES的MPLS Label字段取值为ESI标签值

配置peer esad-route-compatible enable后，MPLS Label字段改为全0
Peer EVI：EVPN单播流量负载分担转发时使用的MPLS标签

以太网自动发现路由扩展团体属性：

多归场景下，Peer ES必须携带ESI Label属性实现水平分割

抓包发现即使是单播网络，Peer ES也会携带ESI Label 属性

Type 2：MAC/IP地址通告路由

MAC/IP地址通告路由 MAC/IP Advertisement Route

用于通告MAC/IP路由，包含RD值、ESI值以及EVPN实例对应的私网标签以及RT、路由下一跳等信息

MAC/IP地址通告路由用于在两个site之间通信时交互MAC路由并形成MAC-VRF表项

只有在发送流量时，才会交互二类路由，可以说二类是EVPN网络控制层的最后一块拼图

以ARP为例，当CE发送ARP的同时，PE会同步将学习到的源MAC地址通告2类路由通告给其他PE设备

ARP本身的发送由Type 3类负责，Type 2只负责通告学习到的MAC/IP地址从而转发已知单播流量

报文格式：

Ethernet Tag ID：该字段在VLAN-Aware接入BD EVPN场景中取值为PE上实际配置的VLAN ID，其他场景中为全0。

MPLS Label1：用于二层业务流量转发

MPLS Label2：可选，用于三层业务流量转发

其余字段略

Type 3：集成多播以太标记路由

集成多播以太标记路由Inclusive Multicast Ethernet Tag Route

集成多播以太标记路由是EVPN建立控制层时最先交互的报文

当PE之间的BGP邻居关系建立成功后，在PE上启动EVPN，PE之间会传递集成多播路由。根据集成多播路由携带的RT值，各个PE上的VPN实例可以感知到其他PE的可达信息以及是否接收其他PE的路由。

NLRI格式：

除NLRI中携带的字段外，在集成多播路由中还携带PMSI和RT属性

RT用于标识EVPN实例要不要接收此路由，PMSI属性如下:

PMSI用于携带多播报文传输的隧道类型和隧道标签信息（即到达报文发送者的MPLS标签）

Type 4：以太网段路由

以太网段路由Ethernet Segment Route，主要用于DF选举

以太网段路由携带本端PE的ESI、Source IP和RD值（IP:0），用来自动发现同一ES的PE设备，并选举出DF

以太网段路由通过携带扩展团体属性Import RT实现路由过滤

路由过滤：只允许和Type 4路由发送者同一ES的PE接收该路由，其他PE接收该路由

通过比较扩展团体属性Import RT的信息实现

Type 5：IP前缀路由

IP前缀路由IP Prefix Route。用于L3VPN或者在EVPN网络接入侧将外部IP信息通过进EVPN网络

在EVPN VPLS中用于实现和外部网络互通

EVPN接入方式/服务模式

ES有四种接入接入EVPN网络的方式，又称EVPN服务模式

上述对EVPN VPLS原理解析中举例的配置全部为VLAN Based模式，四种模式具体区分以及配置方式如下：

Port Based模式

连接CE的物理接口直接绑定普通EVPN实例，且该接口不创建子接口。只能用于承载二层业务

int g1/0/0
interface Ethernet1/0/0
 evpn binding vpn-instance e  # 绑定evpn到物理接口
 esi 0000.0000.0000.0000.1111   # 指定ESI

多次实验，EVPN路由全部交互完成，但无法ping通对端，原因不明

VLAN Based模式

将连接CE的物理接口划分为多个子接口，每个子接口关联不同的VLAN且加入不同的广播域，每个广播域又绑定单独的一个EVPN实例。

可以承载二层、三层业务

这种模式特点是：一个VLAN —— 一个BD域 —— 一个EVI

接入配置见路由交互原理解释

多归场景中同属一个ES的PE要将Eth-Truck口绑定到e-trunk聚合组，完成跨设备链路聚合的工作

VLAN Bundle模式

这个模式中一个BD域绑定多个VLAN，一个BD域绑定一个EVI

这个模式中，接入同一EVPN实例的用户共有一张MAC-VRF表，所以要求用户MAC地址唯一。

支持二层三层业务

配置就是多个子接口都绑定一个BD域，其他的和VLAN Pased没有区别

VLAN-Aware Bundle模式

这个模式中一个EVPN绑定多个BD域绑定，每个BD域唯一绑定一个VLAN

接入EVPN实例的用户使用独立的BD域（BD-TAG）、共有同一张MAC-VRF转发表

在VLAN-Aware Bundle模式下，形成负载分担的MAC/IP地址通告路由与以太自动发现路由，不仅需要比较ESI是否一致，还需要比较路由的BD-Tag是否一致，如果BD-Tag不一致表示路由属于不同的广播域BD，无须形成负载分担。

如果该场景中使用了VLAN-Aware Bundle的服务模式，则每个BD-Tag都会生成对应的以太自动发现路由，所以系统必须从一个PE收到指定EVPN实例对应的所有广播域BD的以太自动发现路由，才能让该PE参与DF选举。

对于基于接口的DF选举，系统会选择广播域BD内第一个Up的接口进行选举。

EVPN跨域三方案使数据中心的内容，这里暂略

GRE概述

GRE(通用路由封装)并不是一种具体的VPN，而是一种封装方法的名称

在VPN隧道中，我们把使用的协议分为三种

载荷协议：VPN承载的协议，私网协议
封装协议：VPN使用的协议
承载协议：报文在公网传输的协议

对于MPLS VPN中，载荷协议是IPv4、封装协议和承载协议都是MPLS LDP

GRE VPN是根据GRE思想建立的一种点到点隧道

对于GRE与GRE VPN 我的理解如下：

GRE是一种封装的方法

设备读写数据报文的本质是一个逐层解封装的过程，因为已经事先定义好了协议的报文条目，所以只要设备知道某段比特流是什么报文，就可以读取出数据。现网环境也是这么做的，通过一些手段标识本层，通过Protocol字段指明上层，让设备得以确定对应的比特流

VPN的本质是给载荷协议封装一层承载协议，比如IPv6封装到IPv4中。但这个思想有个很严重的问题，以IPv4封装IPv6为例，IPv4是三层协议，IPv6也是三层协议，IPv4的报文不支持Protocol字段指向IPv6（protocol指向传输层协议的协议号，而IPv6协议只有协议类型）。

GRE的方法就是一个人为定义的中间层，还是以IPv4封装IPv6为例，首先IPv4上层协议指向GRE，然后让GRE上层指向载荷协议，这样设备得以正确读取多个相同层封装的比特流，隧道（VPN）也得以实现

从这个角度考虑，现在很多的VPN协议都采用了GRE的思想

其他不以GRE封装方法实现隧道的协议一定是可以直接指明上层报文的协议，比如2.5层的MPLS，以MPLS标签转发报文，可以直接指明上层，所以MPLS并不以GRE思想封装

GRE基本原理

GRE提供了将一种协议封装到另一种协议的方法，是一种三层（L3）隧道封装技术

GRE 协议号：47

GRE隧道能够承载IPv4/IPv6的单播、组播、广播报文

GRE报文格式：

GRE是一种VPN封装协议，报文头部位于承载协议和载荷协议之间。

如果是IPv4 over IPv4，则GRE头部在公网IP头和私网IP头部之间

其实现原理是给私网IP报文通过GRE的方式再封装一层公网IP报文，使其以公网报文的身份在公网传输。

报文字段解释：

C（Checksum）:校验和验证位，置为1标识报文插入了校验和字段
K（Key）：关键字位，置为1标识报文插入了关键字(Key)字段
Recursion：递归字段，标识报文GRE封装的层数，每封装一层GRE该字段就加1，大于3时丢弃报文，防止报文被无限制的封装
Flags：保留，当前必须为0
Protocol Type：上层协议（载荷协议）的类型
Checksum：可选，只有C位置位时存在该字段，标识校验和
Key：可选，只有K位置位时存在，标识关键字

GRE工作原理：

这里以IPv4 over IPv4，分支访问总部为例

分支与总部已经建立了GRE隧道，分支报文到达出口设备，查表发现去往总部的路由下一跳是GRE隧道接口
报文根据GRE隧道的配置封装公网源目IP地址
查表发现公网下一跳，从公网接口转发
总部公网出接口收到报文，解封装后转发到GRE接口，还原为载荷报文交由总部私网转发

GRE VPN的优点与缺点

GRE VPN优点

可以以IP网络为承载网络，VPN应用的范围大，限制小
可以承载多种上层协议，不局限与单播，任何从Tunnel接口发出的存在三层的报文都可以被GRE封装。
- 所以GRE支持传递动态路由协议报文和组播
配置简单，部署方便

GRE VPN缺点

GRE是一种点对点隧道，隧道双方的地位是平等的，只适用于Site-to-Site的连接
GRE VPN隧道接口的地址是静态配置的，想要改变配置，就必须同步修改隧道两端
在多站点互联的场景下，GRE需要实现Full-mesh(全互联)随着站点数量的增加，GRE隧道数量呈平方上升
GRE只提供了有限的校验机制，不提供加密机制，安全性不足
每个通过GRE的数据包都会经过两次查表，但路由器在不绑定VPN实例的情况下只有一张表。
- 所以GRE在IP over IP的场景中，公网和私网的地址不能重复，并没有真正的分割公网和私网以实现独立的地址空间

GRE隧道的维护机制

GRE Keepalive检测

在隧道两端不启用动态路由时，一旦隧道中间的链路down，GRE隧道并不能及时的得知并修改网络状态

Keepalive就是GRE隧道为了检测链路状态设定的机制，启动Keepalive的Tunnel会周期向对端发哦是那个Keepalive报文，如果3各周期没有收到对端的Keepalive报文，认为隧道异常，关闭Tunnel接口

Keepalive超时时间 = Keepalive发送周期 * 重试次数
缺省发送周期和重试次数华为和华三有所区别
- 华为：发送周期5s，重试次数3次
- 华三：发送周期10s，重试次数3次
所以在两端设备属于不同厂商时需要注意给两端配置相同的发送周期

动态路由协议本身就具备链路状态检测机制，所以在两端运行动态路由协议时，可以不开启Keepalive

华三设备缺省不启动Keepalive功能，开启需要执行如下命令：
```
keepalive 10 3 # 使能keepalive功能，发送周期10s，重复次数3次
```

GRE Key关键字

在没有身份校验的情况下，非法用户可以通过伪造IP地址的方式和站点建立GRE连接访问内部网络。

Key关键字用于对Tunnel接口进行验证，防止错误识别。配置KEY后，key不同的报文不能建立GRE连接

华三设备缺省不使用Key验证，启用需要执行如下命令：
```
gre key 123456 # 使能key并设置key为123456
```

GRE数据校验

GRE可以对GRE头部以及Payload字段计算一个校验和，将包含校验和的字段随报文一起发送给对端。

对端收到报文后再次对报文计算检验和，如果计算结果一致则接收报文，否则丢弃报文。

华三设备缺省关闭数据校验，使能需执行以下命令：
```
gre checksum # 使能校验和计算 
```

建立GRE VPN（H3C设备）

通过静态路由使隧道互通

RTA：
interface GigabitEthernet0/0
 ip address 11.11.11.1 30
interface Tunnel0 mode gre
 ip address 192.168.1.1 30
 source GigabitEthernet0/0  # 设置源地址使用g0/0接口地址（也可以直接指定一个地址）
 destination 11.11.11.2 # 设置目的地址
 keepalive 10 3 # 使能Keepalive
 gre key 123456 # 使能关键字验证
 gre checksum # 使能数据校验
ip route-static 2.2.2.2 32 Tunnel0
ip route-static 192.168.1.0 30 Tunnel0 # 配置去往对端站点的路由下一跳是Tunnel接口

RTB对地址做出更改即可

通过动态路由协议建立隧道

interface GigabitEthernet0/0
 ip address 11.11.11.1 30
// 注意：使用动态路由建立GRE隧道不能宣告公网接口
interface Tunnel0 mode gre
 ip address 192.168.1.1 255.255.255.252
 ospf 1 area 0.0.0.0 # 将tunnel接口宣告到ospf
 source GigabitEthernet0/0
 destination 11.11.11.2
// 使用动态路由协议可以不配置keepalive
 gre key 123456  
 gre checksum  # 使能GRE校验

如果在动态路由协议中宣告了公网地址，ospf状态会在Full和init之间震荡
这是由于公网原本由公网协议互通，VPN也通过公网协议创建的路由建立，一般是静态
启动ospf后，GRE隧道正常，ospf状态为Full，由于ospf优先级为10，路由表认为ospf交互的公网路由更优，所以使用ospf学到路由代替原本的公网路由
路由表变化，GRE隧道断开，OSPF 从Full->init，从OSPF学的的对端公网路由消失
GRE隧道又重新以原公网路由条目建立GRE，OSPF从Init->Full
循环重复以上过程

所以在使用动态路由协议时，不能将公网接口宣告进去

其他命令

display interface Tunnel 0 # 查看tunnel 0 接口运行情况
display interface Tunnel 0 brief # 查看tunnel 0 接口运行情况简略信息

建立GRE VPN (Huawei设备)

interface Tunnel0/0/1  # 创建隧道接口
 ip address 10.10.10.3 255.255.255.0 
 tunnel-protocol gre  # 指定隧道协议为GRE
 source GigabitEthernet0/0/0  # 指定源
 destination 10.1.23.3  # 指定目的
 gre key 123456  # 设置GRE关键子
 gre checksum  # 使能GRE校验
 keepalive  # 开启keepalive，华为缺省发送周期5s,发送3个

IPSEC VPN

数据安全基础

安全技术四要素：

机密性：防止数据被窃听
完整性：防止数据被非法篡改
身份认证：认证数据的发送者
不可抵赖性：数字签名、预共享密钥pre-shared-key

保证机密性

数据传输中主要使用各种加密算法保证数据机密性

根据加密方式的不同，加密算法可以分为对称加密和非对称加密两类

对称密钥算法（对称加密）：

对称密钥又有流密码和块密码两种

流密码：加解密时一次加解密一位纯文本，速度快，典型的例子是凯撒密码

现在常用的流密码有：RC4、RC5

块密码：又称分组密码，一次加解密一块纯文本，速度比流密码满，典型的例子是栅栏密码

现在的块密码有：DES 56 bit ，3DES 3*56bit，AES 128、192、256bit，IDEA 128bit国际密钥算法

默认AES的安全性高于DES

DES技术由美国研发，美国国家安全局使用的DES是64bit，转为民用时降为56bit并且没有公开算法源码，所以其安全性未知。最好使用AES算法

非对称密钥算法（非对称加密）：

非对称加密是使用算法实现的一对公私密钥对，其特点是使用公钥加密的数据可以使用私钥进行解密，反之使用私钥加密的数据也可以使用公钥解密。（公钥加密不能公钥解密，私钥亦然）

基于这个特点，数据接收方生成一对密钥，将一个密钥作为公钥传递给发送方，发送方发送数据时使用这个公钥对数据进行加密，然后发送给接收方。接收方收到数据后使用自己留存的私钥就可以完全解密，从而保证数据安全性。

对于对称密钥，由于数据的加密解密都是使用同一个密钥。如果密钥在网络中传递时被截获，非法用户就可以使用截获的密钥解密或伪造数据，所以对称密钥需要保证密钥的安全交换
而非对称密钥公钥加密的数据无法使用公钥解密，即使中途被截获也无法通过这个密钥解密。只需要保证留存在本地的私钥不外泄即可

所以非对称加密的安全性高于对称加密，但非对称加密算法也比对称加密更消耗资源。

目前主流的非对称密钥有三种：

DH：密钥交换算法

这个算法主要是为了通过非对称密钥传递一个对称密钥，可以用于加密、数字签名、密钥交换，过程如下：
- 发送方与接收方都使用DH算法产生一个密钥对，并向对方传递自己的公钥
- 双方用对方的公钥和自己的私钥计算一个密钥X(这里最强的就是两端生成的密钥X完全相同)
- A产生对称加密密钥，通过密钥X加密后发送到B，B用密钥X解密得到这个密钥
- B通过该密钥向A发送数据
现在也可以通过组合密钥来实现，先使用非对称密钥加密对称密钥发送对端，然后通过对称密钥传输数据。既保证了密钥安全性，也可以有较快的传输速度
RSA：用于数字签名和加解密

数字签名和加解密的区别：
- 加解密就是字面意思，使用密钥对数据进行加密和解密
- 数字签名是专门用于身份验证的技术，加解密使用公钥加密私钥解密，数字签名使用私钥加密公钥解密，其原理是：
  
  数据发送方通过自己的私钥对包含自己“介绍”的数据进行加密，并随着数据包发送。其公钥对于网络来说是“公开”的状态，任何持有其公钥的接收方都可以解密数据。
  
  由于私钥加密的特点：一个密钥加密的数据只能由密钥对的另一个密钥解密，所以可以唯一确定数据发送者。私钥没有泄露时无法伪造签名。所以具有不可抵赖性。
- 数字签名的不可抵赖性具有法律效力
DSA：只能用于数字签名

防止数据被篡改

防止数据篡改主要使用Hash散列算法，其特点是不论数据多长，经过运算后总是可以得到一个等长的Hash值，并且这个值可以认为是唯一的。

数据发送方在发送数据时计算数据的Hash值随数据包一起发送，接收方收到数据后通过计算Hash值，并对比收到的Hash值，如果一样则说明数据在传输过程中没有被篡改或者数据丢失，否则认为数据被篡改。

常用的HASH算法有MD4和SHA1、SHA2
注意：思科对于SHA2加密算法与华为和华三有所不同，如果是与思科对接，需要开启特定的命令

但是单纯的使用Hash算法防止数据被篡改仍然无法保证数据不被篡改，篡改者完全可以在篡改数据后重新生成HASH值发送。为了防止这种情况，发送方会通过数据报文和一个密钥共同计算出HASH值。只要篡改者不知道密钥，就无法伪造HASH值，从而防止数据被篡改。

这类使用密钥加密HASH的算法称为HMAC算法，目前主流的有 HMAC-MD5 128bit（16字节）和HMAC-SHA1/2 160bit（20字节）两种。HMAC的密钥称为MAC密钥

公钥基础设置PKI

PKI（公钥开放体系），时一个签发证书、传播证书、管理证书、使用证书的环境。

完整的KPI系统包含权威认证机构（CA）、数字证书库、密钥备份与恢复系统、证书作废系统、应用接口（API）五个模块

终端实体时PKI的最终使用者，CA是一个用于签发并管理数字证书的可信实体。其作用包括：发放证书、规定证书有效期等

CA证书与数字签名的区别：

CA证书就是数字签名，不过一般的数字签名可信度未知，CA证书是有权威机构认证的数据签名

数字签名验证身份虽然方便，但是有两个问题：

无法验证数字签名是否可信
数字签名只能由生成者传递，解密需要生成者公钥，传播混乱，不易管理

CA权威认证机构就是一个警察局的角色，CA证书就是警察局发放的身份证。PKI实体只需要将自己的公钥上传给CA，认证通过后，CA就会生成对应的数字证书并保存到证书库。证书使用者如果想要访问这个实体，直接向CA查询就可以获取证书，从而解决了数字签名的问题。

PKI工作流程：

实体向RA提出申请
RA审核身份信息，将身份信息和公钥以数字签名的方式发送给CA
CA验证数字签名，颁发证书
RA收到证书后发送到LDAP提供目录浏览服务，并通知实体证书颁发成功
实体获取证书，利用该证书与其他实体进行安全通信
实体撤销证书时，向CA发出申请，由CA批准撤销，并更新CRL发送到LDAP服务器

IPSec概述

IPSec是一种安全体系结构，由一系列安全协议组成，属于L3VPN

IPSec VPN是IPSec的具体实现，通过IPSec的思想，在隧道两端交互相同的验证、加密算法，从而建立一条安全的VPN隧道

IPSec缺点：

协议体系复杂难以部署

通过底层Underly网络建立，隧道两端需要协商SA并动态更新密钥。由于不同厂商之间对IPSec的兼容性也不相同，使得IPSec隧道非常容易配置错误
实现加密和验证需要高强度的运算，会消耗大量资源，增加了数据传输的延迟

IPSec吞吐量有限并且与链路带宽无关，视加密算法长度决定，一般为100M，加密算法生成的密钥长度越长，则吞吐量越小
仅能对点到点的数据进行保护，不支持组播（OSPF协议不能再IPSec隧道运行）

现网中IPSec隧道有三种实现方式，常见的有两种：基于ACL受保护流的实现；基于Tunnel接口实现

建立IPSec隧道需要两端设备协商IPSec SA，但是负责IPSec SA协商的报文同样需要被加密，所以需要一个密钥。

SA：安全联盟；是一组特定加解密、认证算法、密钥的集合。由于加密的特性（被加密的数据只有特定的协议才能解密），隧道两端SA规定的各类算法必须一致。

IPSec隧道建立的过程，就是SA协商的过程

根据密钥生成的方式，IPSec隧道又分为手动创建和IKE自动协商

IPSec 隧道构建原理

首先，IPSec VPN具有和其他VPN一致的特性：建立在Underly网络之上，所以在传输过程中，IPSec VPN数据包外层必然封装Underly网络包头

其次，IPSec VPN的目的是实现对数据的加密和认证，加密和认证功能IPSec隧道通过两种协议实现：AH和ESP。根据封装的方式不同，IPSec VPN又有隧道模式和传输模式的区别。

AH：认证头协议；用于实现数据的身份认证

在隧道模式下：

AH报文封装在载荷协议之前，并对包括公网IP报文之内的所有数据进行认证。

为保证认证的hash不被篡改，AH认证中加入了HMAC算法对进一步保证了数据安全性

身份认证机制是基于hash的一种保护，其原理借助了hash的唯一性

只有完全一致的数据才能被hash为相同的值，有一个字节不符合都是差之毫厘、谬之千里【hash雪崩效应】

现阶段虽然已经证实了MD5是可碰撞的（可以被重复），但是概率很低，可以忽略不计

但仅仅使用hash加密存在一定的缺陷，当数据被截获后，如果攻击者在篡改数据的同时修改了hash值，那么使用hash进行通信的双方是不同察觉数据被篡改的

为了解决这个问题，AH认证使用了HMAC算法，即在HASH之间给数据添加一条MAC密钥，HASH时连同密钥一并hash。这样只要篡改者不知道MAC密钥的值，hash后的数据就不会被接收

由于隧道的存在，隧道模式实现站点到站点的传输，可以跨越Underly网络自行组建Overly网络

在传输模式下：

传输模式下AH头封装在私网IP头之后，对包括IP头部的所有数据进行认证hash

传输模式只能实现端到端的数据认证，无法跨越Underly网络

ESP：封装安全载荷协议；同时实现了数据的加密和身份验证

隧道模式：

ESP报头在隧道模式中封装在公网IP报头之后

在封装时，会先根据指定加密算法对整个私网数据进行加密，然后使用HMAC算法对加密后的数据进行认证

其认证范围不包括公网IP报头，只有ESP报头和全部的公网数据

传输模式：

同AH，封装在IP报头之后，认证加密过程和范围同隧道模式一致，用于端到端的场景

ESP协议同时实现了认证和加密，但其只有认证是必须的（对于认证不通过的数据是否加解密毫无意义）
所以ESP协议根据需要，可以分为既认证又加密、只认证不加密两种场景

ESP和AH也可以一起使用，此时先进行ESP封装，然后在进行AH封装，但由于IPSec本身非常消耗资源，对于并非对安全要求很高的站点不建议同时封装AH和ESP

AH和ESP报文格式以及详细封装过程暂略

需要注意，由于身份认证的hash机制要求报文在传输过程中不能有分毫改变，所以已经完成AH或ESP封装的报文均不能跨越NAT

对于AH：由于AH认证会计算公网IP头，所以AH不能跨越任何NAT
对于ESP：ESP不会计算公网IP头，所以ESP可以跨越静态NAT，但转换了端口号的NAPT不能跨越

对于跨越NAT建立IPSec的场景，可以使用NAT穿越功能实现。如果IPSec使用IKEv1动态协商，那么IKEv1第一阶段必须为野蛮模式

手动建立IPSec隧道

手动建立基于ACL受保护流的IPSec隧道(Underly网络配置略)

# 以AR1为例
acl number 3000  # 配置受保护的流
 rule 5 permit ip source 1.1.1.1 0 destination 2.2.2.2 0 

ipsec proposal 1  # 配置安全提议
 encapsulation-mode tunnel  # 缺省，设置IPSec为隧道模式
 transform esp  # 缺省，设置安全协议为esp
 esp authentication-algorithm md5  # 缺省,设置认证算法为MD5
 esp encryption-algorithm aes-128  # 设置加密算法为AES-128,缺省为AES-256
 //  安全提议中认证算法和加密算法的缺省值随设备型号改变有所不同
 
ipsec policy 1 1 manual  # 配置IPSec安全策略,手动模式
 security acl 3000  # 配置受保护的流为acl 3000
 proposal 1  # 引用安全提议1
 tunnel local 192.168.1.1  # 配置隧道本地地址
 // 手动模式必须配置，IKE协商场景根据路由选择源地址，可以不配
 tunnel remote 192.168.1.2  # 配置隧道远端地址
 // 手动、IKE协商主模式、IPSec普通配置必须配置，IKE野蛮模式、IPSec模板方式视情况可以不配
 sa spi inbound esp 20000  #  指定IPSec出向SA SPI
 sa spi outbound esp 10000  # 指定IPSec入向SA SPI
 // IPSec SA是单向的，双向IPSec 隧道需要建立两个SA
 sa string-key inbound esp cipher 654321  # 指定出向SA密钥
 sa string-key outbound esp cipher 123456  # 指定入向SA密钥

interface GigabitEthernet0/0/0  # 进入接口视图
 ip address 192.168.1.1 255.255.255.0 
 ipsec policy 1  # 使能IPSec策略1

基于Tunnel接口实现IPSec隧道不支持手动模式配置，只能通过IKE自动协商密钥实现

IKE协议原理

IKE协议是用于动态协商密钥的协议，用于IPSec又不仅仅用于IPSec（其他场景不常见）

IKE有两个版本：IKEv1和IKEv2，目前IKEv1较为常见，但IKEv2的应用也在逐渐增加

IKEv1

IKEv1的报文交互有两个阶段：IKESA协商阶段（分主模式和野蛮模式两种），IPSec SA 协商阶段（快速模式）

第一阶段负责协商IKE SA ，最终目的是协商IKE协议的加密算法与认证算法，最终得到一个用于IPSec 保护交互的密钥

根据报文交互的不同，分为主模式和野蛮模式
第二阶段负责协商IPSec SA，通过第一阶段协商得到的密钥，加密IPSec交互的报文进行IPSec加密与认证算法以及相关密钥的协商

IKE SA协商

对于主模式的IKE协商，双方共交互6个报文，并在第4个报文时完成IKE密钥的交互，后续5、6报文通过密钥加密后再交互进行身份验证

消息①和②用于策略交换

发起方发送一个或多个IKE安全提议，响应方查找最先匹配的IKE安全提议，并将这个IKE安全提议回应给发起方。匹配的原则为协商双方具有相同的加密算法、认证算法、认证方法和Diffie-Hellman组标识。
消息③和④用于密钥信息交换

双方交换Diffie-Hellman公共值和nonce值，用于IKE SA的认证和加密密钥在这个阶段产生。
消息⑤和⑥用于身份和认证信息交换（双方使用生成的密钥发送信息），双方进行身份认证和对整个主模式交换内容的认证。

IKE安全提议指IKE协商过程中用到的加密算法、认证算法、Diffie-Hellman组及认证方法等。

nonce是个随机数，用于保证IKE SA存活和抗重放攻击。

野蛮模式只有三个报文交互，IKE发起者在第一阶段就向对端传递IKE SA所需的全部信息，对端收到后也一次性同意，极大的简化了IKE报文交互的流程

消息①和②用于协商IKE安全提议，交换Diffie-Hellman公共值、必需的辅助信息以及身份信息，并且消息②中还包括响应方发送身份信息供发起方认证
消息③用于响应方认证发起方。

在安全性方面，由于主模式从第四个报文后就是加密传输，而野蛮模式全部都是不加密传输，所以主模式安全性高于野蛮模式

对于配置便捷性，野蛮模式支持一端IP地址不固定的场景（IKE协商只能由地址不固定的一方发起），主模式要求两端地址必须可知。同时野蛮模式还支持NAT转化和以域名的方式标识对端

主模式中ID在第五、六个报文中交互，当一个设备有多个对等体时，由于其对等体的id 信息在消息5.6中才会发送，此时主模式的设备只能使用3.4中的ip地址源地址来找到与其对应的预共享密钥，所以在5.6阶段之间主模式都不能建立起有效的身份验证。想让前四个报文正常交互，必须已知对端IP地址

而野蛮模式第一个报文就包括了全部的信息，可以直接建立起身份验证，就不用强制要求IP必须提前可知，但由于第一个报文的目的IP是必须提前得知的，所以野蛮模式只能由地址不固定的一方向地址固定的一方发送

在总部-分支的场景中，一般总部IP固定，分支IP不固定

基于ACL受保护流的IPSec隧道

主模式

以AR1为例，AR2配置与AR1基本一致，Underly配置略

配置IKE(IKEv1)

ike proposal 1  # 创建IKE安全提议，名称为1
 encryption-algorithm aes-cbc-128  # 指定ike加密算法，缺省为des-cbc
 authentication-algorithm md5  # 指定认证算法，缺省为sha1
 dh group1  # 指定DH组,缺省为group1

ike peer 1 v1  # 创建ikev1对等体，名为1
 pre-shared-key simple 12345678  # 设置预共享密钥（用于IKE初始的报文交互）
 ike-proposal 1  # 使用IKE安全提议1(可以有多个,IKE两端按最先匹配的来)
 exchange-mode main  # 缺省为main,指定IKE第一阶段主模式协商
 local-id-type ip  # 缺省为IP,指定使用IP地址进行身份认证
 local-address 192.168.1.2  # (可选)本地地址
 remote-address 192.168.1.1  # (主模式必须)对端地址

一般情况下本端IP地址不需要配置，只有以下三种场景中本地地址必须配置

当安全策略实际绑定的接口IP地址不固定或无法预知时，可以执行命令local-address address指定设备上的其他接口（如LoopBack接口）IP地址作为IPSec隧道的本端IP地址。
当安全策略实际绑定的接口配置了多个IP地址（一个主IP地址和多个从IP地址）时，可以执行命令local-address address指定其中一个IP地址作为IPSec隧道的本端IP地址。
当本端与对端存在等价路由时，可以执行命令local-address address来指定IPSec隧道的本端IP地址，使IPSec报文从指定接口出去。

DH算法是最终决定密钥生成的算法，不同的DH组生成的密钥长度不同，所以DH组在IKE中也必须配置一致，默认为group1

配置IPSec

acl number 3000  # 配置IPSec感兴趣流
 rule 5 permit ip source 2.2.2.2 0 destination 1.1.1.1 0 
 
ipsec proposal 1  # 创建IPSec安全提议
 transform { ah | esp | ah-esp }  # 配置使用的协议，缺省为ESP
 encapsulation-mode { transport | tunnel }  # 配置IPSec模式，缺省为tunnel
 esp authentication-algorithm sha1  # 指定认证算法，缺省为md5
 esp encryption-algorithm aes-128  # 指定加密算法，缺省为des

ipsec policy 1 1 isakmp  # 创建IPSec策略，使用IKE动态协商
 security acl 3000  #  配置感兴趣流
 ike-peer 1  # 指定使用的IKE策略
 proposal 1  # 指定使用的IPSec安全提议
 tunnel local 192.168.1.2  # 可选，指定隧道本地地址
 pfs dh-group2  # 可选，指定前向安全使用的DH组，缺省未使能，建议使用14

interface GigabitEthernet0/0/0
 ip address 192.168.1.2 255.255.255.0 
 ipsec policy 1  # 应用到接口

tunnel local和IKE一样，一般不需要配置，只有在上面提到的三种情况【端口IP不固定或不止一个、等价路由】时需要配置

pfs前向安全性：开启后IKE第二阶段的协商不再直接信任第一阶段IKE协商得到的密钥，而是会自己再重新通过DH算法生成一个密钥用于二阶段报文协商

华为基于IKE的IPSec和华三Comware v5版本的IPSec均不需要配置远端地址，远端地址以IKE中的配置为准

野蛮模式

野蛮模式虽然可以在一端IP地址不固定的场景中使用，但由于其本身并没有自动配置的机制，所以往往不能单独配置，一般会在以下几种情景中使用：

隧道两端地址固定，配置野蛮模式只是为了节约资源。此时配置方式和主模式一致
隧道两端有一端地址不固定，为了使IP固定端可以指定远端IP地址，两端使用fqdn（完全用户名）而非IP地址验证身份
隧道两端有一端不固定，且不想使用fqdn，可以在地址固定端配置IPSec模板
IPSec模板可以自动解析收到的IPSec报文，提取其中SA源地址为本端隧道目的地址，其报文源目地址反向为本端感兴趣流

也就是说，配置IPSec模板的一方完全可以只配置加密和认证算法，其他的都从对端获取

IPSec协商也必须由非模板配置的一方发起
- IPSec模板不仅仅用于野蛮模式，还可以用于主模式
- 常见的使用场景有：野蛮模式、多分支站点互通的主模式和野蛮模式
隧道两端IP均不固定，使用DDNS（动态域名解析协议），通过域名验证身份配置野蛮模式建立隧道

以IPSec策略模板为例配置IKE野蛮模式

AR1配置（IP固定端）：

ike proposal 1  # 配置IKE安全提议
 encryption-algorithm aes-cbc-128
 authentication-algorithm md5
ike peer 1 v1  # 配置IKE对等体
 exchange-mode aggressive  # 配置为野蛮模式
 // 由于对端IP未知且由IPSec策略模板反向生成，不需要配置IP地址
 pre-shared-key simple 12345678
 ike-proposal 1
 
ipsec proposal 1  # 配置IPSec安全提议
 esp encryption-algorithm aes-128
ipsec policy-template 1 1  # 配置IPSec安全模板
 // 安全ACL由IPSec反向生成，无需配置
 ike-peer 1
 proposal 1

ipsec policy a 1 isakmp template 1  # 使用策略模板创建安全策略
interface GigabitEthernet0/0/0
 ipsec policy a  # 将安全策略应用与接口

AR2（IP不固定）

// ike proposal和ipsec proposal 配置与AR1相同

ike peer 1 v1  # 配置IKE对等体
 exchange-mode aggressive  # 指定为野蛮模式
 pre-shared-key simple 12345678
 ike-proposal 1
 remote-address 192.168.1.1  # 必须，配置对端地址
 // 地址不固定端必须配置固定端远端IP
 
ipsec policy 1 1 isakmp
 security acl 3000  # 配置受保护流(地址不固定端必须配置)
 ike-peer 1
 proposal 1
interface GigabitEthernet0/0/0
 ipsec policy 1

IPSec策略模板部署多分支场景的IPSec隧道

实验组网：

AR3为总部，建立AR3到AR4和AR6的IPSec隧道，为了简化配置，AR3使用IKE主模式+IPSec策略模板配置

AR3配置：（Underly网络配置略）

ike proposal 1  # 创建ike安全提议，加密算法默认
ike peer 1 v1  # 创建ike对等体，不配置远端地址
 pre-shared-key simple 12345678
 ike-proposal 1

ipsec proposal 1  # 创建IPSec安全提议，加密算法默认
ipsec policy-template 1 1  # 创建IPSec策略模板, 不配置感兴趣流
 ike-peer 1
 proposal 1

ipsec policy a 1 isakmp template 1   # 使用模板创建策略
interface GigabitEthernet0/0/0
 ipsec policy a  # 应用到接口

由于IPSec策略模板可以自动反转远端地址和感兴趣流，所以远端地址和感兴趣流都可以不配置。

如果配置则按配置的来

这样不论连接多少个分支，都可以让策略模板自己完成隧道建立，不需要人工去创建新的策略

AR4/AR6配置（以AR4为例）

acl number 3000    # 创建感兴趣流
 rule 5 permit ip source 4.4.4.4 0 destination 3.3.3.3 0 

ike proposal 1  # 创建安全提议
ike peer 1 v1  # 创建ike对等体
 pre-shared-key simple 12345678
 ike-proposal 1
 remote-address 10.1.12.1  # 指定远端地址，分支必须指定

ipsec proposal 1  # 创建IPSec安全提议
ipsec policy 1 1 isakmp  # 创建IPSec 策略
 security acl 3000  # 指定感兴趣流
 ike-peer 1
 proposal 1
 
interface GigabitEthernet0/0/0
 ipsec policy 1  # 应用到接口

GRE over IPSec

IPSec 可以保证数据安全性，但是由于其进行了加密和认证的缘故，不能运行组播协议，依托于组播的OSPF自然也不能运行

GRE隧道可以运行所有的IP协议，但是不能保证数据安全

为了可以在保障安全性的同时运行OSPF，现网常用的做法是将数据进行IPSec封装后再送入GRE隧道进行传输，这就是GRE over IPSec

即同时再链路上起IPSec和GRE，GRE先封装，然后通过IPSec加密传输到对端。真正负责传输的是IPSec，GRE只是为例保留其组播数据

目标：AR3-AR6之间通过GRE over IPSec封装

interface Tunnel0/0/1  # 创建隧道接口
 ip address 10.10.10.3 255.255.255.0 
 tunnel-protocol gre  # 指定隧道协议为GRE
 source GigabitEthernet0/0/0  # 指定源
 destination 10.1.23.3  # 指定目的
 ospf enable 10 area 0.0.0.0  # 将隧道接口宣告到OSPF 10
 
acl number 3000  # 设置感兴趣流
 rule 5 permit ip source 10.1.12.1 0 destination 10.1.23.3 0 
 // GRE over IPSec隧道中感兴趣流为GRE源目地址
# IPSec其他配置按主模式正常配置即可

基于Tunnel接口实现IPSec隧道

不同于基于ACL的IPSec保护，基于Tunnel接口的IPSec隧道保护所有路由到虚拟隧道接口的报文

但一个Tunnel只能起一个IPSec隧道，如果需要起多个隧道，需要使能多个Tunnel接口

IKE所有配置、IPSec安全提议配置均和基于ACL方式一致

IPSec策略配置不同基于ACL，基于ACL中配置IPSec安全策略，但基于虚接口配置IPSec安全框架(ipsec profile)

ike proposal 1  # 创建IKE安全提议
ike peer 1 v1  # 创建IKE对等体
 pre-shared-key simple 12345678
 ike-proposal 1

ipsec proposal 1  # 创建安全提议
ipsec profile 1  # 创建IPSec框架
 ike-peer 1
 proposal 1

interface Tunnel0/0/1  # 开启Tunnel接口
 ip address 10.10.10.2 255.255.255.0   # 配置私网地址
 tunnel-protocol ipsec  # 指定隧道协议为IPSec
 source GigabitEthernet0/0/0  # 指定源地址
 destination 192.168.1.1  # 指定目的地址
 ipsec profile 1  # 指定使用的IPSec安全框架

Tunnel场景不需要在IKE中配置远端地址，以Tunnel配置的目的地址为准，除非IPSec profile中IKE peer冗余

基于Tunnel接口实现的IPSec隧道也可以基于模板配置，基于ACL中称为策略模板，基于Tunnel中称为隧道模板，两者功能以及用法是一样的，都可以配合野蛮模式使用或用于总部连接多分支的场景

隧道模板会自动为每个访问本端的IPSec隧道都开启一个Tunnel隧道接口

但ensp模拟器不支持，所以这里就贴个配置：

interface tunnel-template [interface-number]  # 进入Tunnel-Template接口视图。
 ip address [ip-address] { mask | mask-length }  # 配置Tunnel-Template接口的IPv4私网地址。
 tunnel-protocol ipsec  # 配置Tunnel-Template接口的封装模式为IPSec方式
 source [ip-address | interface }  # 配置Tunnel-Template接口的源地址或源接口
 ipsec profile [profile-name]  # 在Tunnel-Template接口上应用安全框架
 // 目的地址不需要配置，根据隧道对端的报文反转生成

一个Tunnel-Template接口只能应用一个安全框架。一个安全框架也只能应用到一个Tunnel-Template接口上。

修改Tunnel接口下的source或destination配置会导致接口下应用的安全框架被清除；
修改Tunnel-Template接口下的source配置会导致接口下应用的安全框架被清除；

Atmujie

http://atmujie.github.io/2023/05/20/Datacom-HCIE/

本博客所有文章除特別声明外，均采用 CC BY 4.0 许可协议。转载请注明来源 Atmujie !

网络工程

省钱小妙招:腾讯云COS部署Hexo博客

2023-06-05 Atmujie

IT小妙招

IPv6网络技术

2023-05-14 Atmujie

网络工程

HCIE Datacom RS 部分

IGP高级特性

OSPF高级特性

快速收敛

RPC-部分路由计算

智能定时器

OSPF IP FRR

OSPF与BFD联动

路由控制

等价路由

缺省路由

Filter-lsa-out

其他特性

OSPF多进程

OSPF联动BGP

转发地址 FA

OSPF GR（平滑重启）

NSR与NSF

IS-IS高级特性

快速收敛

I-SPF

LSP快速扩散

路由控制

缺省路由

其他特性

ISIS多实例和多进程

分片与分片扩展

ISIS GR

BGP高级特性

正则表达式

BGP对等体组：Peer Group

原理描述

配置命令

路由匹配工具 ： AS_Path Filter

原理描述

配置命令

路由匹配工具：Community Filter

原理描述

配置命令

出口路由过滤器：ORF

原理描述

配置命令

BGP安全性

BGP认证

MD5认证

Keychain认证

BGP GTSM(通用TTL安全保护机制)

RR组网

单集群RR组网

单集群RR组网问题

多集群RR组网

RR组网示例

4字节AS号

MPLS L3VPN跨域

Option A方案

Option B方案

不带RR场景

带RR场景

Option C方案

方式一：

方式二：

EVPN VPLS

EVPN概述

EVPN 基本原理

EVPN术语：

EVPN路由

EVPN路由交互——启动阶段

激活EVPN

Type 3路由交互

Type 4路由交互

Type 1路由交互

EVPN流量转发——转发阶段

Type 5路由——引入外部路由信息

EVPN报文详解：

Type 1：以太网自动发现路由

Type 2：MAC/IP地址通告路由

Type 3：集成多播以太标记路由

Type 4：以太网段路由

Type 5：IP前缀路由

路由匹配工具： AS_Path Filter