[c-nsp] How to measure Layer2 VLAN utilization in IOS
All, I have a question about monitoring of traffic volumes in a Cisco based metro Ethernet environment. I have a mixture of local switching and EoMPLS VLAN services configured on the same pair of customer access ports. As you would expect, the EoMPLS PW's are switched across the wide area and the local switching is simply between VLAN's configured on both ports in the pair. I can easily see the EoMPLS statistics in terms of packets sent and received by issuing the show mpls l2transport vc x detail command, however I simply cannot see how to obtain the same level of detail with respect to the local switched services. For example, the EoMPLS statistics are as follows: nsn1#sho mpls l2transport vc 101 detail | inc totals packet totals: receive 589562735, send 589488418 byte totals: receive 75464030080, send 2440073472 However, for a local switched service, the best I can obtain is: nsn1#sho vlan counters * Multicast counters include broadcast packets Vlan Id: 100 L2 Unicast Packets : 83244 L2 Unicast Octets : 10322256 L3 Input Unicast Packets : 0 L3 Input Unicast Octets: 0 L3 Output Unicast Packets : 0 L3 Output Unicast Octets : 0 L3 Output Multicast Packets: 0 L3 Output Multicast Octets : 0 L3 Input Multicast Packets : 0 L3 Input Multicast Octets : 0 L2 Multicast Packets : 0 L2 Multicast Octets: 0 In which case, I see the general VLAN utilisation in terms of packets and octets, but cannot determine the direction, source, destination, ingress, egress port etc...I have tried querying the SMON mib for the device using SNMP but this demonstrates the same information. I will look into what I can glean using netflow, but this seems like overkill when all I really want are some simple L2 switching statistics via CLI/SNMP. The node in question is a Cisco ME6524; however I think that this is a general problem in IOS. Does anyone have any ideas/recommendations? Many thanks James. ___ 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/
Re: [c-nsp] Netflow performance
Manuel, It depends upon the exact hardware configuration you have (SUP/PFC/DFC etc..) but on more recent components such as the SUP720, mls netflow functions are supported by a dedicated ASIC in hardware. This means that enabling mls netflow has no impact on the forwarding performance of the device. The ASIC simply listens to packets that are routed by the PFC, every time the device considers that a flow has expired, it passes the flow information to the Netflow Data Export (NDE) function and clears the cache entry, ready for re-use. It's worth bearing in mind though that the NDE function is completed by the MSFC in the slow path and hence can tend to drive up the CPU on the device. We have completed some testing in our labs here on a 7600 with SUP720. We used our test kit to generate 60K concurrent flows with randomly inserted TCP SYN and FIN flags set (loosely emulating pseudo-random TCP sessions) and observed no performance difference with and without netflow enabled. Interestingly, this test generated an average NDE traffic volume (using NDE version 5) of about 1Mbit/sec. One thing to bear in mind is the level of NDE aggregation and the impact that this has on your management network and MSFC CPU utilisation. Hope this helps James. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Manuel García Montero Sent: 14 February 2008 14:03 To: cisco-nsp@puck.nether.net Subject: [c-nsp] Netflow performance Hi, Any advice in how netflow can affect the performance in a 6509? currently the 6509 provides wccp (8 squids cache farm), with 40 MB of ram used (366.9MBytes free), cpu stable at 1-2%, and supports ~500Mbps of throughput ... I was planning the following typical config (i can attach the rest of the config if needed) mls netflow mls aging normal 60 mls aging long 64 mls flow ip interface-full mls nde sender version 5 mls nde interface ip flow-export source IP_Router ip flow-export version 5 peer-as ip flow-export destination Collector_IP Collector_Port ip flow-aggregation cache source-prefix mask source 255.255.255.0 with C Class aggregation in order to reduce flows size ¿is this premise true? Thanks. ___ 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/ ___ 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/
Re: [c-nsp] Nexus 7000
Lincon, Just on the netflow point, whilst it's all very well being able to generate a ton of netflow data export records, but has the Cisco Netflow Collector been sufficiently scaled to deal with the sort of volumes of traffic generated by these next generation platforms? What type of hardware platform would I need to use as a collector if I enabled netflow (or even sampled netflow) on a number of these devices in my data centre!?! James. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lincoln Dale (ltd) Sent: 29 January 2008 12:30 To: Ray Burkholder; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Nexus 7000 Does it do netflow output? yes, NetFlow export v5 and v9 (flexible netflow) export are supported. h/w table of 512K netflow entries shared between ingress egress on each forwarding engine (per I/O module). Or sampled netflow? yes, (true) sampled netflow is supported in h/w too. I suppose one would need a small network just to handle the netflow output of a fully traffic'd switch. quite possibly! in the initial software release the export is handled by the Supervisor control-plane. in a maintenance release soon after, we're adding distributed netflow export such that its exported from the control-plane local on the I/O module. even with the centralized model, its forseeable that there could be substancial export rate! cheers, lincoln. ___ 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/ ___ 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/
[c-nsp] Cisco ME-6524 platform architecture
Dear all, I stumbled across this excellent forum yesterday whilst trying to gain some information on the platform architecture of the Cisco ME-6524. I have been extensively testing this device for a couple of months now, using a mixture of local switching, multiplex-uni and EoMPLS with MPLS-TE FRR. So far, it has performed remarkably well, especially considering its price point as an entry level device to the Cisco 6500 family. I do however have a question regarding the platform architecture of the box. As I'm sure you all know, the architecture of the modular 6500 series is very well documented by Cisco, including details of the modules (PFC, MSFC etc..),types of ASIC (Pinnacle, Medusa, Earl, Tycho and Superman etc..) and how they interoperate at a high level. The part I'm struggling with is how this relates to the fixed configuration of the ME-6524. I appreciate that its based upon the SUP-720, and utilises MSFC2A with PFC3C, but I when I issue a show asic-version slot 1, I don't see any ASIC names that I recognise: nsn1#sho asic-version slot 1 Module in slot 1 has 5 type(s) of ASICs ASIC Name Count Version KUMA 1 (2.0) HYPERION 1 (6.0) R2D2 1 (2.0) DHANUSH 2 (2.0) VISHAKHA 8 (1.0) Can anyone help with some more detailed information relating to the platform configuration of this device? Many thanks in advance James Humphris IP Engineering, Nexagent Ltd. ___ 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/
