zoukankan      html  css  js  c++  java
  • VLAN之QinQ技术浅析

    http://www.h3c.com.cn/MiniSite/H3care_Club/Data_Center/Net_Reptile/The_One/Home/Catalog/200911/655247_97665_0.htm

    ==========================================

    QinQ技术(也称Stacked VLAN 或Double VLAN)是指将用户私网VLAN标签封装在公网VLAN标签中,使报文带着两层VLAN标签穿越运营商的骨干网络,在公网中只根据外层VLAN标签传播,私网VLAN标签被屏蔽,这样,不仅对数据流进行了区分,而且由于私网VLAN标签被透明传送,不同的用户VLAN标签可以重复使用,只需要外层VLAN标签的在公网上唯一即可,实际上也扩大了可利用的VLAN标签数量。

    QinQ的标准是IEEE802.1ad(IEEE802.1ad的全称是:Virtual Bridged Local Area Networks Amendment 4: Provider Bridges)该标准是在2006年5月份才形成正式标准的,所以当前我们常见的各厂商实现的QinQ和该标准有较大的不同,但各厂商的实现均大同小异。

    本文分为两大部分,第一部分主要介绍当前常见的QinQ的各个方面,第二部分介绍802.1ad以及该标准同当前我们所常见的QinQ的区别。

    1         QinQ

    1.1        QinQ的产生

    1、随着三层交换机的不断成熟和大量应用,许多企业网和小型城域网用户都倾向于使用三层交换机来搭建骨干网,由于以下三个原因,这些用户一般都不愿意使用基于MPLS或者IP协议的VPN:

    ·           配置、维护工作相对比较繁杂;

    ·           许多厂商的三层交换机不支持MPLS功能,如果用户搭建基于MPLS的VPN,势必要淘汰这些设备,浪费资源;

    ·           支持MPLS功能的单板一般价格昂贵,小型用户难以承受。

    而QinQ可以提供一种廉价、简洁的二层VPN解决方案,不需要信令协议的支持,可以通过纯静态配置实现,而且只需要网络边缘设备支持QinQ,内部只需要可以支持802.1Q的设备即可,所以越来越多的小型用户倾向于使用该功能构建自己的VPN网络。

    2、运营商在通过Ethernet提供Internet接入业务时需要对客户标识,做到精细化管理,而且随着新业务的开展(如Triple-Play、Wholesale、VPN),运营商还需要对业务进行细分,以区别提供不同的管道、QoS策略。原有基于802.1Q只有4096个vlan标识不能满足这样的需要,QinQ正好可以扩展这样的标识,同时还可以利用不同的VLAN来区分运营商的服务和不同的客户。利用QinQ提供接入时具用以下的优点:

    · 可以解决日益紧缺的公网VLAN ID资源问题;

    · 用户可以规划自己的私网VLAN ID,不会导致与公网VLAN ID冲突;

    · 提供一种较为简单的二层VPN解决方案;

    · 使用户网络具有较高的独立性,在服务提供商升级网络时,用户网络不必更改原有的配置;

    · 可以按不同层次的VLAN ID来区分不同的业务;

    · QinQ技术上完全可以多层嵌套,没有限制,仅受Ethernet报文长度的限制,具有很好的扩充性。

    本文分为两个部分,第一部分介绍当前常见的QinQ的实现及应用,第二部分介绍802.1ad的基本概念和知识以及同常见的QinQ的异同。

    1.2        QinQ报文封装

    QinQ的报文封装就是在原有802.1Q报文中的TAG头上再加上一层TAG封装,用来扩展VLAN的范围,如图1所示:

                                                                                                                                                                              图1 QinQ报文封装

    1.3        QinQ的报文转发过程

    在通过QinQ实现简单的二层VPN过程中报文是按如下方式转发:

                                                                                                                                                                        图2 QinQ报文转发过程

    图2中在运营商网中使用VLAN20来标识客户A、VLAN30标识客户B,当客户A的报文到达运营商的边缘交换机时,边缘交换机均给客户A的报文打上一个外层标签(VLAN20),然后在VLAN20中转发,不会转发到VLAN30,报文在离开运营商网络时再剥离掉外层的标签,转发到用户A的网络,从而实现一个简单二层VPN功能。

    1.4        QinQ报文的TPID值可调功能

    TPID(Tag Protocol Identifier,标签协议标识)是VLAN Tag中的一个字段,IEEE 802.1Q协议规定该字段的取值为0x8100。IEEE 802.1Q协议定义的以太网帧的Tag报文结构如下:

                                                                                                                                                                    图3 IEEE 802.1Q报文结构

    通常在QinQ中设备的内外层标签的TPID值均采用协议规定的0x8100,但是某些厂商的设备将QinQ报文外层Tag的TPID值设置为0x9100或0x9200,为了和这些设备兼容,并提供较高的灵活性,我司支持QinQ功能的交换机基本上均提供了QinQ报文TPID值可调功能(需要注意有的设备整机支持,有的设备是端口支持),能修改QinQ设备的外层标签的TPID值。(在本文的802.1ad部分我们将会看到802.1ad所规定的TPID为0x88a8,所以当设备同标准802.1ad设备作QinQ对接时也需要TPID可调功能)。


    1.5        灵活QinQ(Selective QinQ)

    在前面我们所讲的QinQ中,通常是以物理端口来划分用户或用户网络,当多个不同用户以不同的VLAN接入到同一个端口时则无法区分用户。另外前面的QinQ方案是一种简单二层VPN的应用,在运行营商接入环境中往往需要根据用户的应用或接入地点(设备)来区分用户,基于这种应用产生了灵活QinQ方案。

    简单讲灵活QinQ就是根据用户报文的Tag或其他特征(IP/MAC等),给用户报文打上相应的外层Tag,以达到区分不同用户或应用的目的。

    当前灵活QinQ主要应用在运营商的接入网络中,在运营商网络中给接入用户分配一个VLAN,以达到便于问题追踪和防止不同用户间互访,用外层标签区分用户的应用;或在接入的环境中用外层标签来区分不同的接入地点,用内外两层标签唯一标识出一个接入用户。在这样的应用中需要BRAS/SR设备支持QinQ的应用(能够终结双Tag)。

    下面我们以S9500为例,看一下灵活QinQ的应用场景:

    在S9500上实施QinQ,并在S9500上进行业务分流,分流的方式是利用灵活QinQ功能,灵活QinQ分流的依据有下面几种:

    1) 根据端口的VLAN区间分流:比如PC的VLAN范围1~1000,STB的VLAN范围1001~2000,网吧的VLAN范围2001~3000;

    2) 根据报文的协议号分流:比如PC采用PPPoE、STB采用IPoE,这些终端都通过一个VLAN上行,可以根据PPPoE和IPoE报文不同的协议号作为QinQ的分流依据;

    3) 根据报文的目标IP地址分流:对于相同源IP地址,相同报文封装不同的业务应用报文,比如PC上的SoftPhone产生的报文,需要根据报文目的IP地址实施灵活QinQ进行业务分流;

    4) 根据QinQ的内层标签的区间,在某些级联交换机的组网模式中,下连的交换机已经实施了基于端口的QinQ,为了实现业务分流,可以根据QinQ的内层VLAN标签的区间实施灵活QinQ进行业务分流。 上述应用场景可以用图4来直观的加以描述:

    S9500

                                                                                                                                                        图4 灵活QinQ对多业务的识别标记

    1.6        BPDU Tunnel(L2 Protocol Tunnel)

    QinQ网络中,运营商网络对客户透明,当客户和运营商网络之间的连接有冗余时必然导致环路问题,如QinQ应用示意图2中的A客户。这就需要运营商网络能透明传输STP/RSTP/MSTP报文,这样客户可以跨运营商网络构建自己的STP树,切断冗余链路。另外为了保证客户全网VLAN配置的一致性,动态VLAN协议如GVRP、VTP等也要求通过运营商网络透传,如果客户使用GMRP作组播应用的话,GMRP报文也要求透传。同时在透传这些报文时,需要区分开不同用户的二层协议报文。

    我们知道以上这些BPDU报文是桥设备的二层控制报文(基本上是以LLC封装的),是与设备全局相关的,不带VLAN Tag,所以需要一种机制来传输用户的二层控制报文,从而引入了BPDU Tunnel (Cisco:Layer 2 Protocol Tunneling)的概念,通过Tunnel来传播用户的二层控制报文。

    通常BPDU Tunnel是这样实现的:当Tunnel端口收到一个用户的BPDU后,把目的MAC修改为一个组播MAC,然后再给协议报文打上用户所属VLAN的Tag信息,组播MAC保证报文在VLAN内广播,同时标识这个报文是个BPDU-Tunnel报文,交换机在收到这个报文时上送CPU处理,还原其BPDU身份,并根据报文中用户所属的VLAN信息,把报文送到相应的客户网络。

    当前我司的实现就采取了上述这种方法,收到用户的BPDU报文后,给这个报文的目的MAC修改为:01-00-0c-cd-cd-d0,再加上运营商分配该用户的VLAN Tag,如图5所示:


                                                                                                                                                                  图5 BPDU-Tunnel报文封装

    2         802.1ad

    IEEE 802.1ad的全称是“Virtual Bridged Local Area Networks Amendment 4: Provider Bridges”,该协议的目标是业务提供商在为客户提供业务时使客户间的服务相互独立,没有相互依赖关系,同时尽量做到业务提供商透明地为客户提供业务。该标准描述了业务提供商(运营商)如何利用和扩展802.1Q在一个统一的网络中为相互独立的客户提供以太网业务。

    2.1        标准化过程

    该协议于2002年12月第一稿,中间历经了多个Draft,并于2006年5月形成正式标准(Amendment to IEEE Std 802.1Q-2005)。文档可从这里获得:http://tech/article.php/4360

    2.2        基本概念

    •            C-VLAN:Customer VLAN,是用户网络内部使用的VLAN;

    •            S-VLAN:Service VLAN,服务提供商网络中使用的VLAN,该VLAN标识VPN用户或者是用户的业务;

    •            Customer Bridge:Customer网络中的Bridge,只能识别C-VLAN;

    •            Provider Bridge:服务提供商网络中的Bridge,根据处理内容的不同又分为S-VLAN Bridge和Provider Edge Bridge。其中S-VLAN Bridge只能识别S-VLAN; Provider Edge Bridge可以同时识别C-VLAN和S-VLAN;

    •            C-VLAN Component:在Bridge内可识别、插入、删除C-VLAN的实体,每个端口一个,对C-VLAN的操作互相独立(两个端口上接收到相同的C-VLAN,但由于属于不同的客户最后的处理结果会不同);

    •            S-VLANComponent:在Bridge内可识别、插入、删除S-VLAN的实体,由于在一个Bridge内不存在相同的S-VLAN属于不同服务提供商的情况,因此在一个桥内只有一个S-VLAN的实体。

    2.3        报文格式

    802.1ad的报文格式,基本同前面我们所讲的QinQ报文格式一致,主要的区别就是802.1ad中重新定义了TPID的值和把原来的CFI位修改为DEI(丢弃标识)位。

                                                                                                                                                                          图6 802.1ad报文封装

    同前面所述的QinQ相比,在802.1ad中明确规定了用户报文和运营商报文的TPID值,从而可以简单的区分用户报文和运营商报文:

    Tag Type

    Name

    Value

    C-VLAN Tag

    IEEE 802.1Q Tag Protocol Type(802.1Q Tag Type)

    81-00

    S-VLAN Tag

    IEEE 802.1Q Server Tag Type(802.1Q S-Tag Type)

    88-a8

    表格 1 802.1ad Ethernet Type allocations

    同时标准中对S-VLAN的TCI位修改为DEI(Drop Eligible Indicator),丰富了QoS特性,当用户报文进入运营商网络时会打上以88a8标识的外层标签,在离开运营商网络时会剥离这个外层标签。

    2.4        802.1ad如何解决Tunnel问题

    在传统的QinQ Tunnel中是通过修改原协议报文的目的地址及加上用户所属VLAN标识来传递用户L2协议报文的(这样做的缺点在于需要在边缘设备上对报文进行修改加重设备CPU的负担)。

    在802.1ad中为C-VLAN及S-VLAN分配了不同的保留地址,在S-VLAN中处理C-VLAN中的协议报文和处理普通的数据报文一样,从而不需要Tunnel就可以透明传输用户二层协议报文。

    Assignment

    Value

    Bridge Group Address

    01-80-C2-00-00-00

    IEEE 802.3 Full Duplex PAUSE operation

    01-80-C2-00-00-01

    IEEE 802.1X PAE address

    01-80-C2-00-00-03

    Provider Bridge Group Address

    01-80-C2-00-00-08

    Provider Bridge GVRP Address

    01-80-C2-00-00-0D

    IEEE 802.1AB Link Layer Discovery Protocol multicast address

    01-80-C2-00-00-0E

    表格 2:保留的地址

    Spanning Tree Protocol

    Provider网络的STP操作和Customer网络的STP操作完全独立运行,相互不关联。在Provider网络内部采用不同的Bridge Group Address(01-80-C2-00-00-08),对于用户的BPDU报文(01-80-C2-00-00-00)作为普通数据报文透传,不进行识别和处理。Provider网络边缘的C-VLAN component端口可以参与用户STP拓扑的计算和用户BPDU的处理。

    GVRP

    Provider网络的GVRP操作和Customer网络的GVRP的操作完全独立运行,相互不关联。在Provider网络内部采用不同的Provider Bridge GVRP Address(01-80-C2-00-00-0D),对于用户GVRP报文(01-80-C2-00-00-21)以及其他的GARP保留地址作为普通数据报文透传,不进行识别和处理。Provider网络边缘的C-VLAN component端口可以参与用户的GARP报文的处理。

    2.5        802.1ad对灵活QinQ的支持

    802.1ad对灵活QinQ的支持同当前常见的灵活QinQ基本一致,在802.1ad中提供了两种确定用户所属S-VLAN的方式:

    1、基于端口(Port-based service interface),在这种模式下用户是根据接入的端口来选择S-VLAN(Service Instance)的

    2、基于C-VLAN(C-Tagged service interfaces),在这种模式下是根据用户使用的C-VID来先择S-VLAN(Service Instance),即同当前我们所见的灵活QinQ类似。


    Meet so Meet. C plusplus I-PLUS....
  • 相关阅读:
    微信二维码 场景二维码 用于推送事件,关注等 注册用户 ,经过测试
    简单的 Helper 封装 -- CookieHelper
    简单的 Helper 封装 -- SecurityHelper 安全助手:封装加密算法(MD5、SHA、HMAC、DES、RSA)
    Java反射机制
    Windows Azure Web Site (13) Azure Web Site备份
    Windows Azure Virtual Machine (1) IaaS用户手册
    Windows Azure Web Site (1) 用户手册
    Windows Azure Web Site (12) Azure Web Site配置文件
    Windows Azure Web Site (11) 使用源代码管理器管理Azure Web Site
    Windows Azure Web Site (10) Web Site测试环境
  • 原文地址:https://www.cnblogs.com/iplus/p/4467347.html
Copyright © 2011-2022 走看看