[c-nsp] EoMPLS - more Sup720 woes

[David Freedman]

Or perhaps not, I'd want to do this on WS-X6148 based blades which don't 
support translation:


switch(config-if)#switchport vlan mapping enable
%VLAN mapping is not supported on this interface.


Guess its workgroup switches then :(

Thans,


Dave.


Marko Milivojevic wrote:
> I can only read this e-mail, nod my head vigorously in understanding your 
> pain. Been there, tried it all -- it's bad :-(
> 
> You CAN use external loopback ports to solve EoMPLS problem with translated 
> VLAN's, but you will be using 2 VLAN's to transport one (with VLAN 
> translation). Also, VLAN translation feature doesn't work on per-port basis, 
> rather on per-port-group (sometimes a single port, sometimes a group of 
> ports on a line card).
> 
> Marko.
> 
> David Freedman wrote:
>> Hiya,
>> 
>> further to my previous post regarding EoMPLS on the 7600/6500 S720 
>> platform, I'm still tearing my hair out over the PFC3 design
>> (see thread entitled "7600: eompls on Vlan")
>> 
>> 
>> We're upgrading our access layer from SupII/GE-OSM to S720 (no OSM)
>> but have customers connected via other means, namely a switch plugged 
>> into a router trunk , with xconnected subinterfaces.
>> 
>> In this configuration, you would have:
>> 
>> Site A Access Switch:
>> 
>> !
>> interface FastEthernet 0/1
>>   description customer access port
>>   switchport mode access
>>   switchport access vlan 100
>> !
>> interface FastEthernet 0/24
>>   description trunk to router
>>   switchport mode trunk
>> !
>> 
>> Site A Access Router:
>> 
>> !
>> interface GigabitEthernet0/1
>>   description trunk to router
>> !
>> interface GigabitEthernet0/1.100
>>   encapsulation dot1q 100
>>   xconnect <SiteB box> 100 encapsulation mpls
>> !
>> 
>> 
>> Site B box ( as supII/OSM)
>> 
>> !
>> interface vlan 100
>>    mpls l2transport route <siteA router> 100 vc-type vlan
>> !
>> interface FastEthernet1/1
>>   switchport
>>   switchport mode access
>>   switchport access vlan 100
>> !
>> 
>> 
>> Meaning that the customer plugs in their kit at Site A into the switch
>> and gets an EoMPLS feed from Site B.
>> 
>> 
>> Now, the lack of SVI Xconnect support on the S720 platform (without the 
>> OSM/SIP) means that. allthough this pseudowire runs in VLAN mode (as it 
>> did before), you can no longer drop the xconnect endpoint on an SVI and 
>> place an access port in it, you have to subinterface an existing 
>> interface, as such
>> 
>> 
>> !
>> interface FastEthernet1/1.100
>> encapsulation dot1q 100
>> xconnect <SiteA router> 100 encapsulation mpls
>> !
>> 
>> 
>> which means that the customer now has an uncolored connection at site A, 
>> via the switch, and a colored (tagged) connection via the box at site B,
>> forcing either the customer to run dot1q with the siteB box, or we need 
>> additional aggregation switching at siteB in order to provide the 
>> uncolored (untagged) access ports.
>> 
>> Since the VLAN space is global for normal cards, once the subinteface is 
>> created, the vlan can't be created elsewhere (i.e as a l2 vlan without 
>> the SVI)
>> 
>> 
>> To further add confusion into the mix , we also need to support dot1q 
>> tunnelling on the access port sometimes (we have a number of QinQ 
>> customers)
>> 
>> My only solution at the moment is to put low end workgroup switching 
>> into site B, which is a real shame, is anybody doing anything simple to 
>> overcome this?
>> 
>> Is it possible to loop back an EoMPLS trunk (of subinterfaces) back into 
>> a switchport trunk (and presumably rewrite the tags somehow in order to 
>> avoid the tag which has been globally consumed)?
>> 
>> 
>> Many thanks in advance
>> 
>> 
>> Dave.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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/
>> 
> _______________________________________________
> 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/
>