802.1ad vs qinq

Hi all,
I trying settings the follow environment.
Exists any tecnology permit the vlans the client 1 go encapsulation into vlan 100 and traffic client 2 into vlan200. I trying follow setting
switchport mode dot1q-tunnel
I reserarching the 802.1ad and qinq the follow ethertype 88a8 and 9100 the diference is qinq is usage only for tunnel? correct?
Regards

I would think it is good practitice to turn off 11b on all APs, but is there any disavantage by doing so?
You should know what your clients before you embark in this activities.  There are still some clients, such as old laptops or USB adaptors to medical equipments to brand new hand-held bar code scanners, that will read nothing but 802.11b and on 1, 2 or 5.5 Mbps data rates.
The reason why these clients are still prevalent is because of the cost to purchase these wireless cards from storage houses. 

Similar Messages

  • ME3400E - 802.1ad, QinQ, EVC

    Hi,
    Ive been reading through documentation and posts in the forum about L2 tunneling EVC etc.. but some items are still confusing so if some people out there can shed some light would be great.
    Im using 7600 with ES+ cards and ME3400E, Aim is to setup a L2 tunnel for a customer over an SP network (I run the SP network)
    Q1. Am I correct in saying that QinQ is proprietary version of the technology while 802.1ad is the standardised version but they essentially achieve the same thing (abit like ISL and dot1q vlans) and you would use either one or the other ?
    For QinQ config like this on the customer facing port should do it
    int g0/1
      switchport mode dot1q tunnel <-- (setup the l2 tunnel for C tagged frames and apply S vlan)
      switchport access vlan 5 <-- the S vlan to apply as the second outer tag
      l2 protocol tunnel  <-- tunnel not process L2 control frames like STP, CDP
    For 802.1ad we achieve the same by saying:
    int g0/1
      ethernet dot1ad uni s-port <-- (setup the l2 tunnel for C tagged frames and apply S vlan)
      switchport access vlan 5 <-- the S vlan to apply as the second outer tag
      l2 protocol forward  <-- tunnel not process L2 control frames like STP, CDP
    Q2. 8021.ad uses a different ethertype 0x88a8 instead of the standard 0x8100 for QinQ which is also used by v802.1q tagged frames - what are the advantages of using a different ethertype, and also what are the advantages of using dot1.ad compared to QinQ ethertype aside ?  Im aware that 0x8100 frames arriving on a 0x88a8 port are considered untagged.  Im just not seeing the reason to deploy with 0x88a8.  Would apreciate any feedback from people using this in their daily operations and some pointers to any useful docs.
    Q3. The above config are lets say a more traditional config approach.  I see that it is possible to also do this with EVC and service instances.
    Would something like the below achieve the same as what I mention in Q1 above ?
    int g0/1
    service instance 1
    encapsulation dot1q
    bridge domain 5
    Is this functionally equivalent to QinQ since we match all tagged frames, we do not pop the vlan tag, but place in bridge domain 5 for forwarding where vlan 5 can be considered as the S vlan ?
    Likewise the 802.1ad equivalent would be:
    int g0/1
      ethernet dot1ad uni s-port
      service instance 1
      encapsulation dot1q
      bridge domain 5
    thanks
    Mark

    I'm far from an expert in Metro Ethernet, but I was facing similar questions
    as you (see also https://supportforums.cisco.com/thread/2200327), so let me give a try :
    > Q1. Am I correct in saying that QinQ is proprietary version of the
    > technology while 802.1ad is the standardised version but they
    > essentially achieve the same thing (abit like ISL and dot1q vlans) and
    > you would use either one or the other ?
    I would agree with that.
    > Q2. 8021.ad uses a different ethertype 0x88a8 instead of the standard
    > 0x8100 for QinQ which is also used by v802.1q tagged frames - what are
    > the advantages of using a different ethertype, and also what are the
    > advantages of using dot1.ad compared to QinQ ethertype aside ?  Im
    > aware that 0x8100 frames arriving on a 0x88a8 port are considered
    > untagged.  Im just not seeing the reason to deploy with 0x88a8.  Would
    > apreciate any feedback from people using this in their daily
    > operations and some pointers to any useful docs.
    The advantage of 0x88a8 is compatibility with non-Cisco equipment,
    especially if that equipment doesn't have a 'Cisco compatibility'
    feature to use 0x8100 for the S-tag.  The Metro Ethernet forum
    (MEF) always consistently mentions 0x88a8 for the outer
    encapsulation (S-tag).
    You can also check out a Cisco document, namely
    http://www.cisco.com/en/US/docs/switches/metro/me3600x_3800x/software/design/guide/CE2.0_certification_v1.pdf
    From what I see there, the 7600 and ASR9000 can interface to unknown Metro Ethernet
    via dot1ad.  I believe that the ME3800X cannot, have seen no options for "dot1ad"
    or "0x88a8" (I mean that probably they can only use 0x8100 for outer tag and you
    can't interface them to non-Cisco equipment).
    > Q3. The above config are lets say a more traditional config approach.
    > I see that it is possible to also do this with EVC and service
    > instances.
    Agreed.
    I will follow this post, please add to this post if you learn something new.
    Patrick

  • IEEE 802.1ad / 0x88a8

    I have moved to another vendor at my edge, and I have continued to use 0x8100 as my ethertype which seems to play nice except for when a customer has a native vlan1 setup.
    Vlan1 will get tagged into my SVLAN 301, but Cisco sees it as an incorrect BPDU, and shuts down the port. I also see customer CDP neighbor information, and other stuff when the customer doesnt prune his network down, or uses vlan1 on transparent lan services.
    My new vendor told me to use the IEEE 802.1ad standard for the outter tag, (ethertype 0x88a8), but Cisco doesnt support it. Does anyone know why Cisco is not following the IEEE 802.1ad standard for provider bridges (Q-Q) tagging on the ME3400 series? I know they developed their own proprietary GBPT protocol for handling of L2 protocols but that doesnt help me now.
    Just some quick searching, shows that the 7600 is supported with 12.2SR. ME3400's are not, its a 'future' release, but I dont know how long ago that document was written.
    *May 10 18:30:30 MST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/1, changed state to up
    *May 10 18:30:31 MST: %SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer vlan id 1 on GigabitEthernet1/0/1 VLAN301.
    *May 10 18:30:31 MST: %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking GigabitEthernet1/0/1 on VLAN0301. Inconsistent local vlan.
    show spanning-tree vlan 301
    VLAN0301
    Spanning tree enabled protocol rstp
    Root ID Priority 4397
    Address 0017.5aaf.f200
    This bridge is the root
    Hello Time 2 sec Max Age 10 sec Forward Delay 7 sec
    Bridge ID Priority 4397 (priority 4096 sys-id-ext 301)
    Address 0017.5aaf.f200
    Hello Time 2 sec Max Age 10 sec Forward Delay 7 sec
    Aging Time 300
    Interface Role Sts Cost Prio.Nbr Type
    Gi1/0/1 Desg BKN*4 128.1 P2p *PVID_Inc
    Gi1/0/2 Desg BKN*4 128.2 P2p *PVID_Inc

    Currently, the default ether type is 0x8100 on a Cisco 7600 for the Q-in-Q outer tag. However, a few non-Cisco vendors use 0x9100 or 0x9200 ether type for the Q-in-Q outer tag. For Cisco 7600 router to operate seamlessly with other vendors it is required to provide a mechanism to change the default ethertype.
    Moreover, there is a need to support ethertype 0x88A8 to support provider bridge defined by IEEE 802.1ad. Custom ethertype feature is proposed as a solution for this problem that enable change of ethertype as per requirements. Under the custom ethertype model, ethertype 0x9100, 0x9200 and 0x88A8 can be configured using "dot1q tunneling" CLI under a physical port.
    Benefits
    The explanation for the error message:
    %SPANTREE-2-RECV_BAD_TLV: Received SSTP BPDU with bad TLV on [chars]
    [chars].
    Explanation The specified interface has received a Shared Spanning-Tree Protocol (SSTP) bridge protocol data unit (BPDU) that was missing the VLAN ID tag. The BPDU has been discarded.
    Recommended Action If this message recurs, copy the error message exactly as it appears on the console or in the system log, call your Cisco technical support representative, and provide the representative with the gathered information.

  • Differentiating between 802.1q and 802.1ad frames

    Does anyone know how to set up a qos policy that can classify based on whether an incoming frame is 802.1q (single tagged) or 802.1ad (double tagged) on an ME3400E?

    Thanks a lot for your suggestion.
    I have played around with this feature and unfortunately it looks like the ingress interface has to be configured as a dot1q tunnel in order for the match inner vlan option to work. We want the interface to be a plain 802.1q trunk interface. Also, to use this feature we would have to know the vlan numbers and match on each one. In our environment the interface will be a UNI to a customer so we will not know (or want to know) the inner vlans being used.

  • Understanding ethertype

    I'm running into an issue with a carrier NNI circuit that is manifesting itself as one-way traffic over an EoMPLS VC.  I believe this behaviour to be the result of the ethertype that the carrier requires us to set on this interface.
    By and large, the IOS-(XE|XR) default seems to be 0x8100, but in this case, the carrier needs 802.1ad/0x88a8.  If I set this ethertype and put an IP address on the subinterface, I can ping across the 802.1ad circuit without issue, like so:
    interface GigabitEthernet0/0/2
    dot1q tunneling ethertype 0x88A8
    interface GigabitEthernet0/0/2.3000
    encapsulation dot1Q 3000
    ip address 1.1.1.1 255.255.255.252
    router#show arp
    Protocol  Address          Age (min)  Hardware Addr   Type   Interface
    Internet  1.1.1.1          -   c89c.1d1d.c902  ARPA   GigabitEthernet0/0/2.3000
    Internet  1.1.1.2          0   001c.25be.63da  ARPA   GigabitEthernet0/0/2.3000
    bpe01.151front711#ping 1.1.1.2
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds:
    Success rate is 100 percent (5/5), round-trip min/avg/max = 58/58/59 ms
    router#
    Now if I attach an EoMPLS tail to this subinterface, ie:
    interface GigabitEthernet0/0/2
    dot1q tunneling ethertype 0x88A8
    interface GigabitEthernet0/0/2.3000
    encapsulation dot1Q 3000
    xconnect 10.10.10.10 69 encapsulation mpls
    With the far end PE being port based, like so:
    interface GigabitEthernet0/16
    xconnect 11.11.11.11 69 encapsulation mpls
    And I stick a wireshark enabled laptop on Gi0/16 of the far end PE, I see untagged traffic coming from behind the 802.1ad link, which is correct, but they don't see anything coming back from me.
    That leads me to believe that there is something with the ethertype possibly not being re-written to 0x88a8 when it's trying to exit the carrier NNI port.  I don't know enough about Ethertype behavior, so I can't be sure this is plausible.
    Does anyone have any pearls of wisdom they can share to help me understand what the correct behavior should be so I can try and deterime what the problem might be?
    Thanks in advance!

    Hi Jason,
    case solved 
    TAC confirmed that issue was caused by CSCti99322 as I was suspecting.
    For the sake of proper documentation of the support forum I am adding the release notes of that defect
    CSCti99322  EoMPLS:  ASR1k dropping QinQ frame received on dot1q subint
    Symptom
    ========
    End to end traffic is not passing over EoMPLS or L2TPv3 xconnect, due to traffic being dropped by the ASR1k due to "BadUidbSubIdx" as seen in the output of "sh platform hardware qfp active statistics drop"
    Conditions:
    =========
    When ASR1k is used as PE. When EoMPLS/L2TPv3 is configured under a dot1Q sub-interface on the ASR,  and if a QinQ frame is received with the outer tag matching the sub-interface dot1Q value.
    Seen in all current IOS software for the ASR1k
    Workaround:
    ==========
    Add second dot1q to ASR1k interface.
    So if originally we had below
    interface Gig0/0.1000
    encapsulation dot1q 1000
    xconnect x.x.x.x encapsulation
    Change it to:
    interface Gig0/0.1000
    encapsulation dot1q 1000 second-dot1q any
    xconnect x.x.x.x encapsulation
    ============
    Fixed in 15.1(03)S through CSCtj03141
    please flag the question as answered and rate it when you have time.
    Riccardo

  • OSM-2+4GE-WAN vs new 7600-ES20-GE3CXL card

    Please can you provide me information about differencess between those 2 modules, considering MPLS support. I am interested in VPLS feature support. Is this new ES20 card support non H-VPLS, like situation where we have access or trunk (dot1q) port on same 7600 router on WS-X6724 SFP card where is MPLS uplink realized with this ES20 card. Generaly,which card OSM or ES20 is better solution for MPLS (L3VPN, EoMPLS and VPLS)feature.

    The 7600-ES20-GE3CXL card has following MPLS features
    Layer 2 VPNs
    ? EoMPLS with MAC learning
    ? H-VPLS (MPLS Edge or IEEE 802.1ad Edge)
    ? Flexible QinQ
    ? Layer 3 VPNs
    ? MPLS VPN (RFC 2547-bis)
    ? Inter-AS and Carrier-Supporting-Carrier
    ? Multicast VPN
    Following links may help you
    http://www.cisco.com/en/US/products/hw/routers/ps368/products_data_sheet0900aecd8057f3ad.html
    http://www.cisco.com/en/US/products/hw/routers/ps368/products_configuration_guide_chapter09186a00801e5bfa.html#wp1002608

  • SPA-1X10GE-L-V2 AND 4-10GBE-WL-XFP SUPPORTED FEATURES

    Hello!
    I am trying to find documents that prove the following:
    4-10GBE-WL-XFP (with CRS-FP40 and XC-L2L3VPN)
    SPA-1X10GE-L-V2 (with CRS-MSC-40G-B AND CRS1-SIP-800)
    FEATURES NEEDED:
    -802.1q encapsulation for L2VPN (EoMPLS & VPLS), L3 and L3VPN
    -802.3ad and QinQ for L2VPN (EoMPLS)
    -Support complete separation of QoS EXP, TOS, DSCP per interface
    -Support complete separation of QoS EXP, TOS, DSCP per VLAN.
    I am still researching to see if I can find supporting cisco documents.
    Thanks in advance,
    Rodrigo

    Hi Rashed,
    I see that your list includes Cisco Insight Reporter and Cisco Service Control Subscriber Manager. Those are SW pieces which will require some servers to run them. You can review the following documents to have an idea of the SW and HW requirements for the servers required to run those components:
    - Insight:
    http://www.cisco.com/en/US/docs/cable/serv_exch/serv_control/broadband_app/insight/rel34/install_guide/insight_34_ig.pdf
    - Subscriber Manager:
    www.cisco.com/en/US/docs/cable/serv_exch/serv_control/broadband_app/rel38x/smug/Installation_and_Upgrading.html
    If you have any doubt, I would strongly suggest you to reach out to your local Cisco Acount Team for these type of questions. They will be able to provide you proper support and guidance for these type of inquires.
    Best regards.

  • WLC LAG to HP switch

    Hello,
    I would like to connect my WLCs (5508) to HP Procurve switches.
    Will I run into any problems if I choose to configure the WLC ports for LAG?
    The 7.0 config guide talks about LAG as being a partial implementation of 802.1ad.
    Also the guide only talks about connecting to a Catalyst.
    I do see that HP also refers to Link aggregation as LAG.
    Will they work together? Or will I have to seperate the AP manager interfaces to seperate ports?
    Thanks,
    Justin

    on the HP, you need to do a Trunk, then set all the VLANS that will exist on the WLC to be tagged.
    On the WLC, enable LAG, and tag all interfaces.  For the AP, it's a standard access port.  So long as the VLAN the AP is on can route to the WLC, it should join.
    HTH,
    Steve
    Please remember to rate useful posts, and mark questions as answered

  • LC/0/0/CPU0:Dec 19 00:48:55 : lda_server[64]: %L2-SPA-5-OIR_ERROR : SPA (0): A SPA hardware or software error occurred on ASR9001

    Dear all,
    i got the problem, suddently my customer router generating that log :
    LC/0/0/CPU0:Dec 19 00:48:55 : lda_server[64]: %L2-SPA-5-OIR_ERROR : SPA (0): A SPA hardware or software error occurred,
    is it the line card is error, and need to be rma ?
    or is there any wrong configuration, or need to be upgraded with FPD.
    the IOS XR version is 4.2.3
    Thanks,
    Budi L

    Hi Alexei,
    here's the log and show hw-module fpd.
    LC/0/0/CPU0:Dec 19 00:48:55 : lda_server[64]: %L2-SPA-5-OIR_ERROR : SPA (0): A SPA hardware or software error occurred, please contact technical support  
    RP/0/RSP0/CPU0:Dec 19 00:48:55 : invmgr[254]: %PLATFORM-INV-6-NODE_STATE_CHANGE : Node: 0/0/0, state: FAILED
    LC/0/0/CPU0:Dec 19 00:48:56 : vic_0[363]: %L2-ETHERNET-6-MTU_NEAR_HW_LIMIT : The configured MTU of 9216 on GigabitEthernet0_0_0_14 is close to the H/W limit, and hence large 802.1Q or QinQ frames may be dropped as oversized frames
    LC/0/0/CPU0:Dec 19 00:48:56 : ifmgr[201]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/19, changed state to Down
    LC/0/0/CPU0:Dec 19 00:48:56 : ifmgr[201]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/19, changed state to Down
    LC/0/0/CPU0:Dec 19 00:48:56 : ifmgr[201]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/18, changed state to Down
    LC/0/0/CPU0:Dec 19 00:48:56 : ifmgr[201]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/18, changed state to Down
    LC/0/0/CPU0:Dec 19 00:48:56 : ifmgr[201]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/17, changed state to Down
    LC/0/0/CPU0:Dec 19 00:48:56 : ifmgr[201]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/17, changed state to Down
    LC/0/0/CPU0:Dec 19 00:48:56 : ifmgr[201]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/14, changed state to Down
    LC/0/0/CPU0:Dec 19 00:48:56 : ifmgr[201]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/14, changed state to Down
    LC/0/0/CPU0:Dec 19 00:48:56 : ifmgr[201]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/13, changed state to Down
    LC/0/0/CPU0:Dec 19 00:48:56 : ifmgr[201]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/13, changed state to Down
    LC/0/0/CPU0:Dec 19 00:48:56 : ifmgr[201]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/12, changed state to Down
    LC/0/0/CPU0:Dec 19 00:48:56 : ifmgr[201]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/12, changed state to Down
    LC/0/0/CPU0:Dec 19 00:48:56 : ifmgr[201]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/11, changed state to Down
    LC/0/0/CPU0:Dec 19 00:48:56 : ifmgr[201]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/11, changed state to Down
    LC/0/0/CPU0:Dec 19 00:48:56 : ifmgr[201]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/10, changed state to Down
    LC/0/0/CPU0:Dec 19 00:48:56 : ifmgr[201]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/10, changed state to Down
    LC/0/0/CPU0:Dec 19 00:48:56 : ifmgr[201]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/9, changed state to Down
    LC/0/0/CPU0:Dec 19 00:48:56 : ifmgr[201]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/9, changed state to Down
    LC/0/0/CPU0:Dec 19 00:48:56 : ifmgr[201]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/8, changed state to Down
    LC/0/0/CPU0:Dec 19 00:48:56 : ifmgr[201]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/8, changed state to Down
    LC/0/0/CPU0:Dec 19 00:48:56 : ifmgr[201]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/7, changed state to Down
    LC/0/0/CPU0:Dec 19 00:48:56 : ifmgr[201]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface GigabitEthernet0/0/0/7, changed state to Down
    LC/0/0/CPU0:Dec 19 00:48:58 : rsi_agent[318]: %OS-RSI_AGENT-6-CARD_ROLE_CHANGE : Based on the card configuration/type, the AFI IPv4 role of the card has changed from Standard to Customer Facing
    LC/0/0/CPU0:Dec 19 00:48:58 : rsi_agent[318]: %OS-RSI_AGENT-6-CARD_ROLE_CHANGE : Based on the card configuration/type, the AFI IPv6 role of the card has changed from Standard to Not Interested
    RP/0/RSP0/CPU0:Dec 19 00:48:58 : invmgr[254]: %PLATFORM-INV-6-NODE_STATE_CHANGE : Node: 0/0/0, state: UNPOWERED
    RP/0/RSP0/CPU0:Dec 19 00:49:02 : invmgr[254]: %PLATFORM-INV-6-NODE_STATE_CHANGE : Node: 0/0/0, state: DISABLED
    RP/0/RSP0/CPU0:CG-PE-05(admin)#show hw-module fpd location all
    Wed Dec 19 05:25:10.591 WIB
    ===================================== ==========================================
                                          Existing Field Programmable Devices
                                          ==========================================
                                            HW                       Current SW Upg/
    Location     Card Type                Version Type Subtype Inst   Version   Dng?
    ============ ======================== ======= ==== ======= ==== =========== ====
    0/RSP0/CPU0  ASR9001-RP                 1.0   lc   fpga2   0       1.12     No
                                                  lc   cbc     0      22.114    No
                                                  lc   rommon  0       1.29     No
    0/RSP0/CPU0  ASR-9001-FAN               1.0   lc   cbc     2      24.114    No
    0/0/CPU0     ASR9001-LC                 1.0   lc   cbc     0      23.114    No
                                                  lc   fpga2   0       1.15     No
                                                  lc   fpga4   0       2.06     No
                                                  lc   rommon  0       1.30     No
    0/0/0        A9K-MPA-20X1GE             1.0   spa  fpga3   0       0.08     No
    Thanks,
    Budi L

  • Spanning tree Stability

    Folks,
    I have recently placed 2 6500 at the core. I am running PVST. I have made one switch as the root primary and the other one is root secondary. My question is what steps can i take to make sure no spanning tree issues arise if some by mistake introduces a switch to the network??? i know i can use the root guard command per interface, but, i was looking for other best practices.
    Also, can someone exlain to me how can i switch modify the spanning tree topology if i have already configured a root bridge with a priority of 1?
    I will surely rate this post.
    Thanks

    Well, you can set the priority to 0;-)
    Except rootguard you mentioned, there is no real way of preventing someone else to become root because even if you set your root priority to 0, a bridge with a lower mac address could beat you.
    STP still assume some kind of cooperation between the switches. If you are in an environment where you absolutely cannot trust the neighbors, you should try avoiding running STP with them. Rootguard is a good safeguard but it will disrupt connectivity when a violation is detected. Plus rootguard will fail to detect problems if the neighbor is hostile and not sending BPDUs at all (bpdufilter).
    If you are operating in a kind of service provider model, you could use l2pt instead (waiting for 802.1ad). In that case, you would just run STP with the bridges you control and trust, and let others tunnel their STPs through you (note that in this case, the untrusted devices can create bridging loops through you, but you can rate limit the bandwidth they are wasting to what they pay for).
    Regards,
    Francois

  • QinQ MTU

    Hello,
    we are using the following configuration to a QinQ link in the subinterface to our users:
    interface GigabitEthernet0/0/0/3.900 l2transport
    description To CUSTOMER - PSEUDOWIRE A
    encapsulation default
    l2protocol cpsv tunnel
    interface TenGigE0/1/0/3.900 l2transport
    description To BACKBONE - PSEUDOWIRE A
    encapsulation dot1q 900 second-dot1q any
    rewrite ingress tag pop 1 symmetric
    Everything is working fine and frames with a payload with 1500 bytes is beeing transported. The issue is that
    a ethernet frame with a payload of 1500 has a total size of 1518 bytes. I know that IOS XR MTU
    concept discard 4 bytes for the ethernet trailer (FCS or CRC). So for Cisco and MTU the original frame size is 1514.
    However the frame received in the GigabitEthernet0/0/0/3.900 has a VLAN TAG because we
    have a trunk to our customer with multiples VLANS. So the MTU size should be 1518. But if we get the
    out of the show interface command:
    sh interface GigabitEthernet0/0/0/3.900
    Wed Sep 12 12:56:32.130 CEST
    GigabitEthernet0/0/0/3.900 is up, line protocol is up
      Interface state transitions: 1
      Hardware is VLAN sub-interface(s), address is 6c9c.ed09.295f
      Description:To CUSTOMER - PSEUDOWIRE A
      Layer 2 Transport Mode
      MTU 1514 bytes, BW 1000000 Kbit (Max: 1000000 Kbit)
         reliability Unknown, txload Unknown, rxload Unknown
      Encapsulation Default,
        Default match
        Ethertype Any, MAC Match src any, dest any
      loopback not set,
      ARP type ARPA, ARP timeout 04:00:00
      Last input never, output never
      Last clearing of "show interface" counters never
         1924812905 packets input, 1293208601922 bytes
         3 input drops, 0 queue drops, 0 input errors
         778056641 packets output, 447390756224 bytes
         0 output drops, 0 queue drops, 0 output errors
    sh interface TenGigE0/1/0/3.900          
    Wed Sep 12 13:02:26.173 CEST
    TenGigE0/1/0/3.900 is up, line protocol is up
      Interface state transitions: 7
      Hardware is VLAN sub-interface(s), address is 4055.3968.7d2b
      Description: BACKBONE - PSEUDOWIRE UPCT-FTALMO
      Layer 2 Transport Mode
      MTU 1518 bytes, BW 10000000 Kbit (Max: 10000000 Kbit)
         reliability Unknown, txload Unknown, rxload Unknown
      Encapsulation 802.1Q Virtual LAN,
        Outer Match: Dot1Q VLAN 900
        Inner Match: Dot1Q VLAN any
        Ethertype Any, MAC Match src any, dest any
      loopback not set,
      ARP type ARPA, ARP timeout 04:00:00
      Last input never, output never
      Last clearing of "show interface" counters never
         778152164 packets input, 450515418508 bytes
         31813 input drops, 0 queue drops, 0 input errors
         1902517045 packets output, 1287687321444 bytes
         308359 output drops, 0 queue drops, 0 output errors
    We have a 1514 bytes MTU instead of 1518 bytes in GigabitEthernet0/0/0/3.900 and 1518 bytes instead
    1522 (there is two 4 bytes tags). Why frames are working fine?. In the following document explains that
    by default the MTU are:
    1514 bytes for normal frames
    1518 bytes for 802.1Q tagged frames
    1522 bytes for QinQ frames
    http://www.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r3.9/lxvpn/configuration/guide/lesc39ethi.html#wp1200718
    How can we explain the 4 bytes difference?.
    Thanks.

    Hello Antonio,
    Here are numbers which are used for L2 MTU calculation:
    "encapsulation untagged” and "encapsulation default”  counts 0 tags. >> 1514
    “encapsulation dot1q 900 second-dot1q any”. The any keyword used as the innermost tag match does not increase the number of tags in the calculation. This is to ensure consistency with the old style XR VLAN Id semantics. >> 1518
    “encapsulation dot1q 900 second-dot1q 900”. No any keyword >> 1522
    but for L2VPN we’d use payload MTU to properly transfer our data.  The rationale behind the payload MTU calculation is to get the correct maximum payload size of frames that may be carried over an xconnected PW relative to the L2 MTU of the interface.
    Let’s take your example:
    interface TenGigE0/1/0/3.900 l2transport
    description To BACKBONE - PSEUDOWIRE A
    encapsulation dot1q 900 second-dot1q any
    rewrite ingress tag pop 1 symmetric
    sub-l2-mtu = parent-l2-mtu + (4 * encaps-tag-count)
    sub-l2-mtu = 1514 + ( 4 * 1 ) = 1518
    sub-l2-payload-mtu = sub-l2-mtu – (14 + (4 * (encaps-pop-tags-count – encaps-push-tags-count)))
    sub-l2-payload-mtu = 1518 - (14 + (4 * (1 - 0)))= 1500
    So we’d be still forwarding 1500b payload.
    You should be able to find your xconnect/BD MTU using “show l2vpn xconnect detail” or “show l2vpn bridge-domain detail”.
    Regards,
    /A

  • Bellsouth Metro Ethernet -- is it QinQ?

    I have a customer who has bought some connections from Bellsouth's Metro Ethernet product. I am having a tough time getting someone at Bellsouth to give me any information about the product.
    Are they just using QinQ (802.1q tunneling) to make it all happen? If that's the case then I should just trunk to them with 802.1q and not have to do anything else, I believe keeping the native vlan 1 should even be fine. If anyone knows anything about this or has connected sites using the Bellsouth metro-e product please let me know.
    Brian

    Hello,
    looks like it is Ethernet over SONET, with a possibility to migrate it to EoMPLS:
    "Currently BellSouth uses a specialty Ethernet switch to support its shared multipoint offering, but that may change. "We're converting to more of a general purpose device that will be part of our MPLS network and will deliver Ethernet and other services," hints Kaish.
    Some carriers have implemented shared multipoint services directly over fiber, which means that those services do not include Sonet restoration capability, effectively limiting them to non-critical traffic. But BellSouth's metro Ethernet network is Sonet-based and customers can leverage Sonet's restoration capabilities, Kaish says."
    http://www.findarticles.com/p/articles/mi_m0DUJ/is_13_107/ai_108408900
    Another source of information supporting the statements above:
    http://newsroom.cisco.com/dlls/2004/prod_070604.html
    In any case this does not mean straight forward, that you can use the service to setup trunks between your switches. This depends on the interface configuration of (presumably) the 7600. They might restrict you to dot1Q with one VLAN or even to plain ethernet.
    Hope this helps! Please rate all posts.
    Regards, Martin
    P.S.: have a look at http://www.metroethernetforum.org/presentations/SC2003_BobSmithEntNet.PDF which should answer many questions! Especially they state "Dedicated Ethernet supports VLAN tagging" - sounds like setting up a dot1Q trunk with them will be supported.

  • QinQ support on Cisco SUP7L-E?

    Current release note for Cisco IOS XE Release 3.2.0XO says:
    These sections list the limitations and restrictions for the current release of Cisco IOS software on the Catalyst 4500E series switch.
    •802.1q tunneling and related features are not supported.
    but in feature navigator there is 802.1q available
    - IEEE 802.1Q Tunneling
    - Selective QinQ
    Sup 6E has support also:
    Be aware that 802.1Q requires WS-C4948, WS-C4948-10GE, ME-4924-10GE, WS-C4928-10GE, WS-C4900M, WS-X4013+10GE, WS-X4516, WS-X4516-10GE, or WS-X45-SUP6-E; Layer 2 protocol tunneling is supported on all supervisor engines.

    Hi Riccardo,
    I checked the tables and for my unterstanding SUP7L-E and SUP7-E are SW feature parity…
    Out of the release note:
    Additionally, Supevisor Engine 7L-E running Cisco IOS 3.2.0XO has feature parity with Supervisor Engine 7-E running Cisco IOS XE 3.2.0SG.
    The feature set for Supervisor Engine 7L-E matches that of Supervisor Engines 7-E
    That means Q-in-Q should also work on SUP7L-E within next IOS release (March – May 2012) … or am i wrong?
    Thanks
    Manuel
    Von: rsimoni
    Gesendet: Dienstag, 10. Januar 2012 16:52
    An: Linder Manuel (CASSARiUS AG)
    Betreff: - Re: QinQ support on Cisco SUP7L-E?
    Home
    Re: QinQ support on Cisco SUP7L-E?
    created by Riccardo Simoni in Other Service Provider Subjects - View the full discussion

  • Cisco Trustsec across QinQ provider network

    Hi,
    We are thinking of using manual CTS encryption on either natively routed ports, or Vlans / SVIs  (Nexus 7ks) to form OSPF adjacencies, but need to understand if this will work across a providers QinQ network. It is my understanding that Trustsec encrypts the 802.1q VLAN tag so ultimately the WAN Provider will receive an untagged packet. So in both cases whether we use a natively routed port, or a Vlan with SVIs, the frames will be untagged.
    So I suppose what I am asking is: Can a QinQ WAN provider accept untagged frames, or do frames have to ingress into the providers network with an underlying Vlan Tag in place?
    Thanks in advance.
    Chris.

    Hi Chris,
    from my tests MacSEC (manual CTS) does not work across QinQ because gcm-encrypt does authenticate via 802.1x (EAPOL frames). And EAPOL ist not tunneled. EAPOL is grabbed by the QinQ interface.
    br Fritz

  • Flexible QinQ/Service Awareness on 7600 12.2(33)SRB

    Hi experts,
    I have a scenario whereby the NPE core-facing links are using the 7600-ES20-10G3CXL with MPLS turned on. The UPE facing links are using the WS-X6724-SFP LAN modules. I would like to know in this kind of setup, is the flexible QinQ feature supported, if configured on the WS-X6724 interfaces?
    For example:
    Module 2 on the 7600 is a WS-X6724-SFP LAN module.
    7600-NPE#conf t
    Enter configuration commands, one per line. End with CNTL/Z.
    7600-NPE(config)#int g2/1
    7600-NPE(config-if)#service instance 999 ?
    ethernet Configure an Ethernet Instance
    7600-NPE(config-if)#service instance 999 ethernet ?
    WORD Attach an EVC to the service instance
    <cr>
    I understand the commands are there, but is this generally a supported feature? Or is the flexible QinQ only supported when a ES20/SIP-400 based card facing UPE is used?
    Note: UPE is a 3750ME/ME3400 with 802.1Q trunk towards the 7600 NPE terminating on the WS-X6724.
    Appreciate your thoughts on this.
    Thanks in advance.

    Hello,
    The config seems to be valid from H-QoS point of view.
    But as per Table 7-3, first row and Note1, on the following CCO link there are restrictions
    from Classification side (class-maps) on ES+:
    https://www.cisco.com/en/US/docs/routers/7600/install_config/ES40_config_guide/es40_chap7.html#wp1337428
    Like, for match ACLs only classify based on source MAC address using Layer 2 ACL
    supported for L2-switchports, EVCs/Port-chan EVCs.
    Deny ACL is not supported on ES+ linecards.
    So if in your class maps classification is based on an ACLs trying to
    match Layer3 (IPs) and/or Layer4 info, those classification options are not supported for ES+.
    And you got those errors.
    If such a case you would need a some kind of re-design, for example, to mark CoS fields on some downstream/access device,
    and then on ES+ ingress l2 interface or EVCs use a class maps
    which would just match on those DSCP/IP_Prec values.
    Thanks,
    Sergey

Maybe you are looking for