[c-nsp] EoMPLS - more Sup720 woes

[David Freedman]

Thanks, but the requirement I have is to transport tagged frames (vlan 
mode) in at one site, especially where we are doing QinQ with people.

If EoMPLS L2VPN interworking
(http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120s/120s26/fsinterw.htm#wp1045913)
was actually available for this platform + my h/w configuration then I 
would have used that.


Dave.


Emanuel Popa wrote:
> Hi David,
> 
> Why not using PORT based EoMPLS instead of VLAN based EoMPLS on the
> SUP720 side? This way you won't need to use subinterfaces, but you
> will have to use one port for each customer.
> 
> The best document for AToM with 7600 and SUP720 would be:
> http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps1838/products_feature_guide_chapter09186a0080134a1b.html
> 
> Good luck,
> Emanuel Popa
> 
> 
> On 3/29/06, David Freedman <david.freedman at uk.clara.net> 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/
>