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.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
