[c-nsp] EoMPLS - more Sup720 woes

[Emanuel Popa]

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