[c-nsp] Sub-int based EoMPLS on a 6700 series LC in a 7600

[Justin Shore]

Gert Doering wrote:
> Hi,
> 
> On Mon, Mar 16, 2009 at 09:46:05PM -0500, Justin Shore wrote:
>> both ends and is the default 1500; I'm thinking that I need to raise 
>> this for one thing, to support the 1Q trunk over EoMPLS.  Or does MPLS 
>> auto-adjust for the higher MTU?
> 
> For basic subif-based EoMPLS, the MTU will still be 1500 (the Q will be 
> stripped off and re-added - so there's no need to use the same VLAN tag
> on both ends either).  The "standard" ethernet header will automagically 
> be taken into account.
> 
> If you do interface based EoMPLS and want to transport VLAN-tagged frames,
> you need to increase the MTU to 1504.

So if I'm touching the CEs with trunks on both ends and a tagged VLAN on 
each end is being used, is the Q tag being stripped as it goes across or 
is it being carried?  Even if it's being carried and the MTU is too low 
to carry the tag on large frames I should still get small frames through 
shouldn't I?  I could always switch the trunks around to put the 
xconnect on the native VLAN on each side.  That's easily done if that 
would help.

> Not on the 7613.  Dunno about the ME boxes.

On the ME3750 I'm using the dedicated GigE uplinks for the core-facing 
ints.  I believe those 2 ports are the only ones that you can enable 
MPLS on for that odd platform.  So that should be ok.

> (We do EoMPLS over 6408A-GBIC, 6724-SFP and 6704-10GE cards, never had any 
> problem with it)

That's good to hear.  So to be clear you're using 6700 series cards both 
for the core-facing interfaces and for the CE-facing interfaces (using 
sub-ints or full ports), correct?

I was pretty sure that this should work.  My TAC engineer got back to me 
last night and is saying that won't work which I don't think is correct. 
  Specifically they said:

"On the 7600, a PFC/DFC or ingress line card (SIP-400/ES20) that does 
EoMPLS Label imposition/deposition is needed as a MPLS uplink port."

Well my 6700 LCs all have DFCs; I wouldn't buy them any other way.  The 
engineer goes on to imply that the VC type on either end is the problem. 
  Well the VC type is the same on both ends and is working because the 
VC is up; a mismatch would keep it down (been there done that).  The 
engineer then gave a description of port-to-port, vlan-to-vlan and 
port-to-vlan modes, their VCs and how the operate on the 7600.  This 
should be a VC type 5 port-to-vlan VC I believe (sub-int to SVI). 
That's what both sides agree on when the VC comes up.

I'm going to call my engineer back and press them on their answer 
because it doesn't seem to be correct.  This should be working.  The VC 
wouldn't be up if the VC type was the problem.

Thanks for the info
  Justin