[c-nsp] EoMPLS - more Sup720 woes

[Alexandre Snarskii]

On Wed, Mar 29, 2006 at 12:05:37PM +0100, David Freedman wrote:
[...]
> 
> 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.

interface fa1/1.100 
 encaps dot 100 native
 xconnect <SiteA> 100 encaps mpls

At least in my test setup 

interface GigabitEthernet4/11.100
 encapsulation dot1Q 100 native
 xconnect <remote> 100 encapsulation mpls
end

this gives me ethernet-vlan vc
Local intf     Local circuit        Dest address    VC ID      Status    
-------------  -------------------- --------------- ---------- ----------
Gi4/11.100     Eth VLAN 100         <remote>        100        ADMIN DOWN

and, as far as 'native' vlan is the same as untagged one - 
that is software-only solution for your problem...  

That does not help with QinQ connections however...