I'm using MAC accounting on our Fast E connection at the PAIX to do per-peer traffic stats. It worked great until we put in a GSR. I don't know why it worked before or if anything has changed since. The stats aren't working now because the # of entries in the MAC accounting table exceed 512 (a hard IOS limit). The majority of these aren't in the ARP table ... they are inbound without translation ... just layer 2 noise. It seems odd to me that there are this many distinct addresses on the same shared segment. Not to mention that the port isn't switched. To wit: 0000.0000.0000(0 ): 110444951 packets, 27399M bytes, last: 80ms ago 0000.0003.0000(3 ): 9416 packets, 2738919 bytes, last: 455680ms ago 0000.037f.4129(20 ): 33 packets, 7700 bytes, last: 302129568ms ago Pretty serious chunks of bandwidth. There are a large group of these addresses that begin with 0000. --- are these some sort of bridged translation? Can you think of any other reason that so many MACs would appear on the same port? --matt hempel
On Tue, Nov 28, 2000 at 02:24:53PM -0500, Matt Hempel wrote:
I'm using MAC accounting on our Fast E connection at the PAIX to do per-peer traffic stats. It worked great until we put in a GSR. I don't know why it worked before or if anything has changed since.
When Cisco released the GSR platform, the dropped MAC accounting from the requirements on all their ethernet boards for that platform. While you could turn it on, the counters were meaningless, sometimes showing you nothing, often showing packets on the wrong bucket. The short story is that "processor switched" packets were counted correctly, but there was no implementation for "ASIC switched" packets, and so they incremented some generic counter. Several people, including myself made a big stink about this issue. My biggest complaint was if they weren't going to implement it, then you shouldn't be able to configure it in the CLI, but that said, it should be implemented. Fortunately Cisco was helpful, and decided to work on implementing it. Support for the 1xGE card was added in 12.0(11) I believe. They just added support for the 3xGE card in 12.0(13). I have never asked myself about the FE cards, but they should be more or less the same issue. If you're not on fairly recent code I recomend trying an upgrade and seeing if that fixes your problem. If not, you should open a tac case for the bug "mac accounting can be configured on FE, but does not work". If you can't get some good answers e-mail me and I'll poke some of the people we've been working with. -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
I'm using MAC accounting on our Fast E connection at the PAIX to do per-peer traffic stats. It worked great until we put in a GSR. I don't know why it worked before or if anything has changed since.
[...]
The forwarding databases in the PAIX switches have, at most, 119 MAC addresses; we've assigned 129 IP addresses, and I can pretty easily attribute the 10 "missing" ones to a couple holes in the allocation and some folks who have addresses but haven't turned on their interfaces yet. Looking at the actual forwarding databases, we're running one MAC per port on all but the trunks - we're *very* diligent about preventing non-PAIX layer 2 devices from contaminating our layer 2 fabric. Given that, I think you're suffering from GSR's not being able to do MAC accounting (as Leo suggested) rather than there being any "layer 2 noise" in the switch fabric. The PAIX engineering folks (send mail to <engineering@paix.net>) would be happy to take any follow-up questions you might have about PAIX infrastructure. Stephen
participants (3)
-
Leo Bicknell -
Matt Hempel -
Stephen Stuart