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 <[email protected]>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 <[email protected] > > 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 [email protected] >>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >>> >> >> > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
