双活数据中心是啥意思(双活数据中心技术-OTV)
双活数据中心是啥意思(双活数据中心技术-OTV)Edge Device执行OTV功能:接收所有VLAN的层2交通需要扩展到远程位置和动态封装成IP数据包 然后发送以太网帧在交通基础设施。一个站点可以有多个OTV Edge Devices (多宿主):为了更充分地讨论多宿主,预计至少两个OTV边缘设备部署在每个数据中心网站 提高弹性 .学习OTV控制和数据的飞机是如何工作的 你须了解OTV特定的术语。Edge Device 负责所有OTV功能Edge Device 可以位于站点中的分布层或核心层
双活数据中心技术-OTVOTV的概念引入了“MAC路由” 这就意味着控制面协议用于MAC可达性信息交换网络设备之间提供局域网扩展功能。 从第二层交换 这是一个重大转变 传统上利用数据平面学习 它是合理的层2需要限制洪水的交通在交通基础设施。 强调在整个文档 2层之间的通信网站类似于路由切换。 如果目的MAC地址信息是未知的 那么流量下降,防止浪费宝贵的整个广域网带宽。
OTV也引入了动态封装层2流的概念需要被发送到远程位置。 每个以太网帧分别封装成IP数据包和交付整个交通网络。 这消除了需要建立虚拟电路 称为Pseudowires 数据中心之间的位置。 立即优势包括改善灵活性添加或删除网站覆盖的时候 更优化的带宽利用率在广域网(特别是交通基础设施多播时启用) 和独立于传输特性(一层一层1、2或3)层。
最后 OTV提供了一个原生内置多宿主和自动检测功能 增加整体解决方案的高可用性的关键。 两个或两个以上的设备可以利用每个数据中心提供局域网扩展功能没有运行的风险 创建一个端到端的循环会危及的整体稳定性设计。 这是通过利用相同的控制面协议用于MAC地址信息的交换 不需要扩展扩充树协定(STP)覆盖。
以下部分详述了OTV技术和引入内部署OTV 和数据中心之间替代设计。
- OTV术语
学习OTV控制和数据的飞机是如何工作的 你须了解OTV特定的术语。
- 边缘设备
Edge Device 负责所有OTV功能
Edge Device 可以位于站点中的分布层或核心层
一个站点可以有多个OTV Edge Devices (多宿主):为了更充分地讨论多宿主,预计至少两个OTV边缘设备部署在每个数据中心网站 提高弹性 .
Edge Device执行OTV功能:接收所有VLAN的层2交通需要扩展到远程位置和动态封装成IP数据包 然后发送以太网帧在交通基础设施。
OTV Edge Device
- Internal Interface接口
Internal Interfaces 是Edge Devices连接站点内部的接口,负责承载需要通
过OTV承载的VLAN
Internal Interfaces 是传统的二层接口. OTV Internal Interfaces 不需要进行
任何OTV相关的配置
内部接口是常规层2接口配置为访问或树干港口。 树干配置是典型的同时考虑到需要扩展覆盖多个VLAN。 不需要应用OTV-specific配置这些接口。 同时 典型的二层功能(如当地切换、扩充树操作 数据平面学习 和洪水)执行的内部接口。图1 - 2显示层2的树干 被认为是内部边缘设备之间接口通常部署。
- Join interface 接口
Join interface 是Edge Device的上联接口
Join Interface 是一个点到点的了路由接口,该接口即可以是一个物理接
口,也可以是一个以太网链路通道接口
Join Interface 用来物理上加入整个OTV的网络
- OTV连接接口
- OTV覆盖接口
Overlay Interface 是一个虚拟接口,所有OTV的配置均在该接口上配置
这是一个逻辑上支持多路访问,以及支持组播能力的接口
Overlay Interface 将站内的二层数据帧封装在三层的IP单播或组播的数
据包中,并发送到其他站点
注意事项
如前所述 OTV经营的基本原则之一是使用OTV边缘之间的控制协议运行设备广告MAC地址可达性信息 而不是使用数据平面的学习。 然而 MAC可达性信息可以交换之前 所有OTV边缘设备必须成为“相邻”从OTV的角度来看。 这可以通过两种方式来实现 这取决于交通网络互连各种网站的性质:
•如果启用多播 一个特定的多播组可以用来交换之间的控制协议消息OTV边缘设备。
•如果不启用多播 另一个部署模型可以从其中一个(或更多)OTV边缘设备可以配置为一个“邻接服务器” 所有其他边缘设备注册和通信设备的列表属于一个给定的叠加。
- OTV 数据平面
- OTV 的数据在标准的IP数据包上封装增加了42字节
- 外层OTV shim 头中包含了overlay信息(VLAN overlay number)
- 原先的802.1Q头被移除,并拷贝到OTV的shim头中
- 站内数据流向
- 站点之间的数据流向
- OTV 控制层面
- 创建MAC地址表
- OTV 周期性更新MAC地址可达信息(控制层面学习)
- 一旦OTV被配置,MAC就在系统后台开始通告
- 无需额外的配置工作
- 在不同的Edge Devices之间,OTV控制层面使用IS-IS,作为控制协议。全部自动生成,无需了解IS-IS
- 邻居的发现和邻接关系的形成
- 在MAC地址被通告的其他OTV Edge Devices之前,
- 不同的OTV Edge Devices需要:
- 彼此发现对方
- 并创建邻居关系
- 邻居关系可以基于一个IP网络架构,可以是:
- 支持组播的IP网络
- 只支持单播的IPW网络
- 技术优势: OTV 可以利用任何网络环境(组播,单播,ECMP,快速路由)
- 基于组播环境的邻居发现
- 基于组播环境的MAC地址更新
- 一旦Edge Device 学习到一个新的MAC地址,OTV控制层面将其关联的VLAN ID和IP下一条地址一起更新到远端
- IP下一跳地址为Edge Devices的join-interfaces地址
- 一个OTV 的更新可以包含不同VLAN的多个MAC地址
- 一个更新包使用和邻居发现同样方式到达所有OTV Edge Devices
- 核心网络的组播环境
- OTV 可以利用现有组播环境中优势进行数据层面和转发层面的构建和转发
- 对于组播环境的要求:
- Control group – Single PIM-SM or PIM-Bidir group 用于邻接关系的形成以及MAC地址信息的交换
- Data groups – … discussed later in this presentation
- 配置
- OTV 运行所需要最少配置
- Spanning Tree 和OTV
- 站点独立
OTV 是站点透明设计: 对STP的拓扑结构没有变化
每个站点保持其自身的STP设计
这个功能是OTV内置的功能,无需额外配置
Edge Device 只在Internal Interface发送和接受BPDU
- 未知单播和OTV
- 不支持未知单播在不同的DC之间洪散
- 对于未知单播数据帧将不予转发
- OTV 将不会在overlay接口上转发未知单播数据帧。这是OTV内置的功能,无需配置
- 这里基于一个假设:接入终端不存在单向数据流或非对称数据流
- 控制ARP流量
ARP 邻居发现(ND) 缓存
- 每个OTV的edge device均通过侦听ARP的回复数据来维护一个ARP缓存表
- 第一个ARP请求将广播到所有站点,但以后同样的ARP请求都将由Edge device本地回复
- 跨越多个站点的ARP 数据流将大幅减少
- OTV 自动多宿主支持
- 对于站点多宿主的探测是完全自动的,并且不需要额外的协议和配置
- 站点内的Edge Devices 通过“otv site-vlan”发现对方
- OTV 将针对一组VLAN 选举一个Edge Devices 作为Authoritative Edge Device (AED)
- AED 用来: 针对VLAN的MAC地址通告
- 转发对应VLAN的数据
- 在Edge Devices 之间分担不同的VLAN
- 在同一站点内所有VLAN将分别由不同OTV Edge Devices 承担
- 通过内置的算法决定. 在一个双归属的站点:
Lower IS-IS System-ID (Ordinal 0) = 偶数VLANs
Higher IS-IS System-ID (Ordinal 1) =基数VLANs
3.未来允许进行手工配置
- AED 以及广播包的处理
- 站点内的Edge Devices 均收到广播数据包
- 只有对应VLAN的AED 负责将数据包转发到overlay中
- 另一侧的所有Edge Devices 都将收到广播包
- 只有对应VLAN的AED将该广播包发送到站点中
- vPC 在OTV Edge Devices双活设计
- 在统一个VLAN内,不同的数据流量可以到达不同的的OTV Edge Devices (vPC peers)
- 如果流量达到non-AED设备,流量将穿过vPC的peer-link
- Future Release: Edge Devices 通告MAC 地址并转发所有远端VLAN流量。无需穿越vPC的peer-link
- 路径优化
- 路径优化的挑战
- 二层扩展会带来次优路径的问题
- 这些挑战可能包括网关的位置,以及路由的通告
- 扩展VLAN 的出向路由
- 扩展的vlan通常与HSRP 组通信
- 只有一个HSRP路由器是活跃路由器,所有服务器均将默认网关指向VIP
- Result: 次优路径产生
- 出向路由本地化
- FHRP 过滤方式
- Filter FHRP with combination of VACL and MAC route filter
- Result: Still have one HSRP group with one VIP but now have active router at each site for optimal first-hop routing