[c-nsp] Cisco L2VPN EWS with 7600 (QinQ)

[redscorpion69]

Hello,
so does that mean I need to have native vlan tagging enabled on PE routers?
Then how do we handle untagged traffic from customer switch?

regards


On Wed, Feb 26, 2014 at 9:00 PM, redscorpion69 <redscorpion69 at gmail.com>wrote:

> Hi,
>
> thanks for quick reply.
>
> No we checked that:
>
> all_7600s#show vlan dot1q tag native
> dot1q native vlan tagging is disabled
>
>
> On Wed, Feb 26, 2014 at 8:22 PM, Pavel Stefanov <p.stefanov at v6horizons.net
> > wrote:
>
>> Hello,
>>
>> Do you have "vlan dot1q tag native" configured globally on the 7600s?
>>
>> Pavel
>>
>>
>>
>> On 26/02/2014 19:04, redscorpion69 wrote:
>>
>>> Hello,
>>>
>>> We've been testing different point-to-point L2VPN services on 7600 as PE
>>> routers (in MEF terminology ERS, EWS).
>>>
>>> Basically the topology is this:
>>>
>>>
>>> CE------[ME3600]------[7600]----MPLS-----[7600]---------
>>> enni(dot1ad)-----[7600]--------[ME3400]----CE
>>>
>>> ^
>>> ^
>>>
>>> |
>>> |
>>>
>>> |
>>> |
>>>
>>> QinQ
>>> QinQ
>>>
>>> The idea is that we have (from right to left) an ISP send us S-tagged
>>> customer frames over ENNI, which we then transport over MPLS to leftmost
>>> 7600, which takes out topmost S-tag and forwards frames to customer on
>>> other side.
>>> I think this would be called EWS in MEF terminology or transparent EPL
>>> (not
>>> port-based) in Cisco.
>>>
>>> Anyhow this is the configuration on rightmost WS-card 7600 (which would
>>> belong to other ISP) facing 3400:
>>>
>>> interface GigabitEthernet
>>>   switchport
>>>   switchport access vlan XXX
>>>   switchport mode dot1q-tunnel
>>>   l2protocol-tunnel cdp
>>>   l2protocol-tunnel lldp
>>>   l2protocol-tunnel stp
>>>   l2protocol-tunnel vtp
>>>   no cdp enable
>>>   spanning-tree bpdufilter enable
>>> end
>>>
>>> Same 7600 facing our 7600 over ENNI link:
>>>
>>> interface GigabitEthernet
>>>   switchport
>>>   switchport trunk encapsulation dot1q
>>>   switchport trunk allowed vlan XXX
>>>   switchport mode trunk
>>>   ethernet dot1ad nni
>>> end
>>>
>>> Then, our (middle) 7600 (ES+ card) facing ENNI link:
>>>
>>> interface GigabitEthernet
>>>   no ip address
>>>   ethernet dot1ad nni
>>>   service instance XXX ethernet
>>>    encapsulation dot1q XXX
>>>    rewrite ingress tag pop 1 symmetric
>>>    bridge-domain XXX
>>>   !
>>> end
>>>
>>> There's also interface vlan XXX which XCONNECT-s to our leftmost 7600.
>>>
>>> Finally, leftmost 7600, WS-card facing 3600:
>>>
>>> interface GigabitEthernet
>>>   switchport
>>>   switchport access vlan XXX
>>>   switchport mode dot1q-tunnel
>>>   wrr-queue cos-map 2 2 4
>>>   wrr-queue cos-map 3 1 7
>>>   wrr-queue cos-map 3 2 3 6
>>>   l2protocol-tunnel cdp
>>>   l2protocol-tunnel lldp
>>>   l2protocol-tunnel stp
>>>   l2protocol-tunnel vtp
>>>   no cdp enable
>>>   spanning-tree bpdufilter enable
>>> end
>>>
>>> Here's the thing:
>>> ------------------------
>>>
>>> Tagged L2CP (cdp/stp...), as well as any other customer traffic is
>>> transported fine. 3600 and 3600 see each other.
>>>
>>> But when it comes to untagged traffic, both switches put their interfaces
>>> in inconsistent STP state and block VLAN1 traffic over their trunks. As
>>> far
>>> as I could understand, the receive BPDU containing S-tag info, over Vlan
>>> 1.
>>> I would understand if this happened over normal trunks where different
>>> native vlans are used. But this is our S-tag, and I don't think customer
>>> switches should be able to see anything containing our S-tag.
>>>
>>> Could anyone shed some light on this? Is it possible to transport
>>> UNTAGGED
>>> traffic/L2CP with this configuration?
>>>
>>> regards
>>> _______________________________________________
>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>
>>
>>
>