[c-nsp] Replacement for 3550-12T being used as a router - IPv6 related

[Mark Tinka]

On Monday, April 11, 2011 07:10:34 PM Eric Van Tol wrote:

> Yes, we will do pretty much the same thing.  It's what
> we're doing now for non-v6 enabled switches and seems to
> work.  Traffic load on v6 is low, so static tunnels to
> routers are not a big deal at the moment.

Aye.

The only issue is if customers can't support 6-in-4 
(normally if they're using routers that need additional 
cards to handle tunneling, as most Cisco gear will support 
6-in-4 in software; or routers that don't support tunneling 
or 6-in-4 altogether).

> Looking back on my notes, it wasn't DSCP marking that was
> the issue.  It was classifying/remarking traffic based
> upon source IP address.  This was problematic because we
> needed to make sure that traffic from our customers was
> properly re-marked for our voice network.  We could
> really only do this based upon destination IP.  However,
> we've recently begun deploying low cost NIDs at customer
> locations that can ensure the proper markings for us, so
> we can now just classify based upon DSCP instead of IP. 
> I am told that classifying/remarking based upon IP is
> coming in Q2/Q3 this year.

Alright. We haven't tried to match by IP address.

A few notes on some issues we've found:

	- If you're used to having a 'match any' in your
	  class-map, it's not supported today. This should
	  be coming in the future, but not sure when. For
	  now, 'class class-default' in your policy-map is
	  your friend (which I think we shall be migrating
	  to, as IOS XR suffers from the same problem, and
	  we need consistency amongst our Cisco platforms).

	- If you're used to unconditional marking, that
	  isn't supported either if you're policing as well.
	  However, you can fix this by using conditional
	  marking, where marking is applied as an action to
	  a rate (CIR/PIR) and/or color (conform, exceed,
	  violate). This works!

	- Not having any match criteria blocks traffic when
	  a service policy referencing that custom class-map
	  is used. I suppose this is expected behaviour. I
	  can't recall whether we've seen anything like this
	  on other IOS platforms, but it's not something I
	  can scream at Cisco about. We found it trying to
	  workaround the lack of 'match any'.

> Cool.  Any experience with the MPLS functionality?  We're
> going to go with these as a replacement for the ME3400s,
> as these are 10/100/1000 with a clear upgrade path to
> 10G.  Price is definitely not bad, either.  I don't have
> pricing on the MPLS upgrade yet, but the 10G upgrade
> seems quite reasonable.

MPLS works great, can't complain about it.

We haven't tested MPLS-TE on these outside the lab - it's 
unlikely we'll be needing it (unless a feature we badly want 
is implemented by Cisco).

But basic MPLS forwarding works like a charm. You'll need 
the 'AdvancedMetroIPAccess'. Talk to your friendly account 
team, they can get you a reasonable deal, I'm sure.

There's still tons (and tons) of work needed to bring this 
box to even the levels of a regular Cisco software router in 
terms of features, but it's certainly on the right track. 
I'd recommend it to anyone.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20110427/73bc2841/attachment.pgp>