vlan实现的桥多桥方案比较和设计.docVIP

1 TBS现在的VLAN实现分析： 2 1.1模式分析 2 1.2 TBS实现情况 2 1.3 TBS实现存在问题 2 1.4需求分析 2 2 设计分析 3 2.1设计约束 3 2.2可选方案 3 2.3比较分析 4 2.4方案选择 5 2.5技术分析 5 3技术设计 5 3.1 ebtables钩子 5 3.2 ebt_vlan.c修改 6 3.3 VLAN设备不添加VLAN标签 6 3.4 数据流程 7 3.5 linux shell配置 8 TBS现在的VLAN实现分析： 1.1模式分析 AP的VLAN实现可以分为桥模式和路由模式来考虑： 桥模式：报文在AP中只实现MAC地址的交换，也就是说只在内核的桥进行MAC查表而决定出端口。 路由模式：如果报文方向为LAN-WAN则报文首先流入内核的桥，然后再流入内核的路由表来查表决定出口设备；而如果报文方向为WAN-LAN则报文首先进入内核的路由表然后在进入内核的桥在桥中决定LAN出端口。 1.2 TBS实现情况 TBS使用linux内核的VLAN功能已经实现了通过WAN口设备创建相应VLAN设备，使用 此VLAN设备来解释、创建报文的VLANtag标签，并在也就是对于VLAN的路由模式来说，TBS已经实现了。 对应VLAN的桥模式，TBS现在的页面操作：使用WAN设备创建相应VLAN设备，然后使用此VLAN设备创建桥连接，在将此桥连接跟一个LAN组捆绑，那么跟此LAN组捆绑的LAN端口接收的报文在桥交换后通过此VLAN设备发送出去的时候就可以加上相关的VLAN标签。从这点来说，TBS现在已经实现了根据LAN端口划分VLAN进行桥模式的做法，只是界面配置不直观。 1.3 TBS实现存在问题 TBS VLAN桥模式存在的问题：如果WAN口设备本身也加入到桥中，那么根据此WAN口设备创建的VLAN设备无法生效。这是由于WAN口设备进入桥后再上报linux内核的上层会将skb-dev修改为桥，导致问题发生。那么，现在的TBS VLAN桥模式中WAN口只可以接收带VLAN标签的报文进行桥模式转发，而不带VLAN标签的报文则无法进入桥模式转发。 1.4需求分析 VLAN桥模式后续需求： 根据MAC地址划分VLAN 根据业务类型（流）划分VLAN 设计分析 2.1设计约束 需要与现有功能兼容，否则会导致平台软件大修改； 由于TBS平台软件还在开发中，故VLAN功能需要能够容易合进入后续的平台软件版本； 2.2可选方案 单桥方案： 现在内核的桥为不支持VLAN的桥，单桥的核心是将内核的桥修改为支持VLAN的桥，将桥的mac表修改为使用mac和vlan作为索引，这样在转发查表时就会根据vlan和mac来决定出端口；报文在流出桥时，如果报文需要加tag，则在桥中添加； 桥的端口可以配置PVID和默认优先级； 如果需要根据mac地址或者流来决定报文的vlan时，可以使用ebtables来设置skb-vlan； 多桥方案： 维持内核的桥流程，一个vlan使用一个桥来实现，利用桥之间的隔离来达到vlan的隔离功能，如果报文流出桥时需要加tag，则使用现在设备的vlan设备来实现，也就是说需要根据端口设备创建对应的vlan设备，然后在将此vlan设备加到桥中； 在报文流进桥时，需要添加代码可以根据端口、mac地址或者流来决定报文的vlan，然后引入相应的桥中； 2.3比较分析 下面从代码复杂性、兼容性和可移植性三个方面对两个方案进行比较分析 功能点 比较分析 选择 页面操作： 兼容性：加了VLAN配置页面，必然会跟WAN VLAN配置存在冲突，这里加个规则，如果在VLAN配置页面中的配置的VLAN包含WAN端口，则在WAN VLAN配置的此WAN VLAN设备的IP功能不生效。对于多桥方案，还存在一个WAN VLAN设备创建/删除的冲突问题。 可移植性：单桥方案集中在桥修改，而多桥由于存在冲突问题，移植性比较差。 复杂性：对于单桥将WAN设备加到桥后，还需要桥逻辑以便WAN设备和WAN VLAN设备的IP功能生效。 单桥 LAN组绑定 兼容性：单桥存在冲突性；而多桥配置VLAN时需要创建多个桥，并需要创建相应LAN口设备的对应VLAN设备并加入桥中。由于LAN口设备不发送带VLAN标签的报文，需要LAN口设备的VLAN设备在发送报文时不添加VLAN标签。 复杂性：多桥比较复杂， 多桥 WAN桥 兼容性：在多桥中当WAN设备加入到桥中，WAN口的VLAN设备则无法接收到报文，而单桥则不存在此问题。 复杂性：多桥方案中，为了兼容性，需要做到WAN设备加入到桥后，此WAN口的VLAN设备可以接收到报文，比较复杂。 单桥 2.4方案选择 从功能