[c-nsp] More EoMPLS / c7200 gripes

[David Freedman]

Ok, so , I've more EoMPLS implementation gripes with c7200

NPE-G1 box running 12.3 (mainline), want to use a PA-FE-TX for 
customer's attachment circuit.

Come across the following:

router# sh mpls l2transport hw-capability interface f3/0

<snip>

Transport type Eth VLAN
   Core functionality:
     MPLS label disposition supported
     Control word processing supported
     Sequence number processing not supported
   Edge functionality:
     MPLS label imposition supported
     Control word processing supported
     Sequence number processing not supported


Transport type Ethernet
   Core functionality:
     MPLS label disposition supported
     Control word processing supported
     Sequence number processing not supported
   Edge functionality:
     Not supported <==== Huh?



</snip>

This is telling me essentially that I can ONLY use the PA-FE-TX
for a VLAN mode attachment circuit and not port mode!

Does anybody know the technical reason for this?
It seems the wrong way around from a logical point of view, surely if 
there is a restriction in terms of the PA capability it would be the 
opposite (i.e VLAN mode is too much work and only port mode should be 
supported?)

To add more confusion to this, the G1 ports themselves (g0/1,2,3) seemed 
to have the same restriction!

router# sh mpls l2transport hw-capability interface g0/1 | begin type 
Ethernet

Transport type Ethernet
   Core functionality:
     MPLS label disposition supported
     Control word processing supported
     Sequence number processing not supported
   Edge functionality:
     Not supported <==== Again



So anyway, we still need a port mode xconnect, or rather, the ability 
for the customer to pass in untagged traffic and receive it untagged the 
other end , so came up with the following hack on both PE routers:


!
interface FastEthernet X/Y
  description To Customer
!
!
interface FastEthernet X/Y.100
  encapsulation dot1q 100 native
  xconnect 192.168.0.1 100 encapsulation mpls
!


So, xconnect comes up, but no traffic passes.
I expected this to be the case.

I noted from the output of "show mpls l2transport vc 100 detail"
that traffic was being received and none sent, such:

router#show mpls l2transport vc 100 detail
Local interface: F3/0.100 up, line protocol up, Eth VLAN 100 up
   Destination address: 192.168.10.1, VC ID: 100, VC status: up
     Next hop: 10.10.10.12
     Output interface: Gi0/1, imposed label stack {84 340}
   Create time: 11:03:20, last status change time: 11:03:15
   Signaling protocol: LDP, peer 192.168.10.1:0 up
     MPLS VC labels: local 26, remote 340
     Group ID: local 0, remote 0
     MTU: local 1500, remote 1500
     Remote interface description: Its not going to work, is it
   Sequencing: receive disabled, send disabled
   VC statistics:
     packet totals: receive 2410, send 0
     byte totals:   receive 23583, send 0
     packet drops:  receive 0, send 0


Started all the l2vpn debugs I could think of and nothing yielded 
anything useful.


Whilst I accept that this platform is not really geared to Ethernet edge 
functionality such as this (and that I would probably have more luck 
burning the inbuilt G1 ports up to do so) I'm just left feeling a bit 
bewildered as to why such functionality can be configured, but not work.

I did, eventually find the following caveat:

"–The native VLAN of a trunk must not be configured as an EoMPLS VLAN."

buried deep inside a Catalyst MPLS/L2VPN configuration document here:

http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_guide_chapter09186a008029d19e.html

So am guessing that this caveat applies globally to all EoMPLS 
implementations?



Dave.