[c-nsp] EoMPLS - more Sup720 woes

[David Freedman]

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.