On 15/12/2011 4:06 AM, Mark Tinka wrote:
- IPv6 is in, enabled, and it works well carrying 50+
prefixes and OSPFv3 within our AS. Not a hugely taxing
environment, but IPv6 works.
I tested IPv6 - yes, it's enabled but massively broken:
...
o As much as every bone in my body was saying,
"What's left is v4 stuff, you can't possibly be
thinking about that", I decided to remove an
outbound v4 ACL. And voila! You can imagine how
wide I had to open my mind to do that :-).
Yikes. I don't have this problem in my deployment so far as I have
pushed this job onto edge routers to do this function on all
ingress/egress points to our network.
- Issues CSCtr83500 and CSCtr83418 are fixed - so hardset
and auto speed/duplex ports is no longer a showstopper.
We do see issues in 12.2(52)EY2 where the Gig-E ports don't
report utilization statistics for the interface. I'm not
running any traffic on any of the Gig-E ports in my lab
right now, so can't tell whether this issue is fixed in the
new code.
Not sure whether you're seeing anything like this. The
10Gbps uplink ports are fine, though, even in the older
code. The issue only affects the Gig-E ports.
I'll get a chance to pump some traffic through and test.
I'm not seeing this, no.
But I have noted that VLAN interfaces do not have accurate counters (on
any release). This is unlike my ME6524 and 7600's where I have SNMP
pollable counters for these interfaces.
As it stands now, I'm glad to see that the issues with QoS
are not hardware related, so far.
For example applying a very basic 10M
inbound and outbound policer on a VLAN interface to rate
limit a customer for example, is not as simple as say, a
software based router.
We normally apply the service policy either on the physical
interface or EVC.
My requirement has to date been to do this on VLAN interfaces - maybe I
should look into doing this on an EFP on this platform to see if it's
any better.
I've been able to get away with this functionality on 7200s and
1800/1900/2800/2900 ISR's and more or less on the 7600 and ME6524 in the
past:
policy-map police-10M
class class-default
police cir 10240000 bc 1250000
conform-action transmit
exceed-action drop
On those platforms this allows me to rate limit (in both directions if
need be) a customer port or VLAN or subinterface to 10M and is
presumably independent of whether the traffic is IPv4 or IPv6. The
point is it's simple and it works.
Trying to apply this on the ME3600X results in:
sw6.nsw(config-if)#service-policy output police-10M
QoS: Invalid target for service-policy
QoS: Configuration errors for policymap police-10M
sw6.nsw(config-if)#
sw6.nsw(config-if)#service-policy input police-10M
QoS: Invalid target for service-policy
QoS: Configuration errors for policymap police-10M
sw6.nsw(config-if)#
The documentation:
http://www.cisco.com/en/US/partner/docs/switches/metro/me3600x_3800x/software/release/15.1_2_ey/configuration/guide/swqos.html
suggests it's not nearly that straightforward to set up, and looks more
like Catalyst QoS hell :-(
Note: there are 21 pages of resolved caveats in this
code compared to the original 15.1(2)EY release. It's
undoubtedly a good thing that problems are being fixed,
however 21 pages of caveats resolved (about 180 bugs)
and IPv6 support appearing is arguably more than a
"minor rebuild" as the version number would indicate,
but sounds rather like some serious fixes have gone on
behind the scenes.
Do you have a link to the release notes? I normally follow
the one in the download section but that one definitely
isn't 21 pages long :-).
http://www.cisco.com/en/US/docs/switches/metro/me3600x_3800x/software/release/15.1_2_ey/release/notes/ol25360.html#wp954239
Additionally the configuration guide now includes a section on
configuring IPv6.
PS: some key things we're still missing on this box (there's
more but these are the ones I think the list would find
more generic across operators):
- v4 and v6 uRPF support.
- EVC SNMP monitoring.
- 4-byte ASN support.
- MC-LAG.
Yep I'm still missing a bit of basic stuff too - picture this:
- A wholesale carrier hands off a 1G dot1q trunk port to us
- Each end customer is assigned an individual VLAN on that trunk by the
carrier
- We need to be able to rate limit/police (or shape I guess) all traffic
in and out on the specific EVC/VLAN for a customer to a given contracted
amount (tricky if it works at all)
- We also need to be able to see and graph interface counters for each
EVC/VLAN for Cacti/Solarwinds (at present this does not work on VLAN
interfaces)
Now:
sw1.qld#show ethernet service instance detail
Service Instance ID: 780
Service Instance Type: static
Associated Interface: GigabitEthernet0/15
Associated EVC:
L2protocol drop
CE-Vlans:
Encapsulation: untagged
Interface Dot1q Tunnel Ethertype: 0x8100
State: Up
EFP Statistics:
Pkts In Bytes In Pkts Out Bytes Out
52516561 14944728475 56861858 28340980592
May be useful to graph throughput, but it's not clear if these stats
appear in SNMP or not (or if they are accurate or not). But it does
look somewhat promising in that the numbers exist, are large, and
increasing.
Reuben
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
