[c-nsp] EoMPLS - more Sup720 woes

[Marko Milivojevic]

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/
>