Perhaps I am using this feature wrong, but I don't think so. This morning, I am trying to get mac-address accounting working on a 7507MX/RSP8/12.0.17S/GEIP+ running ISL, to indentify large peers off an ethernet peering fabric. I've done 'ip accounting mac-address out'. I then wait. Then, I: core1.nyc#sho int g0/0/0 mac-accounting GigabitEthernet0/0/0 to external peers and customers Output (475 free) 0001.64da.bc00(3 ): 2 packets, 179 bytes, last: 3036ms ago 0004.de2b.e41c(9 ): 1 packets, 99 bytes, last: 3036ms ago 00e0.52a6.1f00(11 ): 1 packets, 99 bytes, last: 3036ms ago 0100.0c00.0000(13 ): 57198 packets, 37155973 bytes, last: 388ms ago 0030.7bee.fc54(13 ): 2 packets, 218 bytes, last: 2836ms ago All of the mac-addresses listed in this 'sho' are valid, except for '0100.0c00.0000', which doesn't exist: core1.nyc#sho arp | inc 0100 core1.nyc# All the others are valid, yet they are way, and I mean *way* under the amounts that I know I am sending to that peer. Any clues? I've searched CCO/Bug Toolkit, I don't see anything relevant.
"ar" == Alex Rubenstein <alex@nac.net> writes: core1.nyc#sho int g0/0/0 mac-accounting GigabitEthernet0/0/0 to external peers and customers Output (475 free) [...] 0100.0c00.0000(13 ): 57198 packets, 37155973 bytes, last: 388ms ago [...] core1.nyc#sho arp | inc 0100 core1.nyc#
01:00:0c is Cisco's Ethernet multicast address prefix. 01:00:0c:00:00:00 looks strange to me. The cisco-nsp mailing list had a query about this problem: http://puck.nether.net/lists/cisco-nsp/0318.html But I don't know whether this has been resolved. If I try outbound MAC accounting (usually I only use inbound MAC accounting at exchange points) on a 7206VXR running 12.0(17)S, everything looks fine.
All the others are valid, yet they are way, and I mean *way* under the amounts that I know I am sending to that peer.
(Maybe your Cisco multicasts all traffic out to the exchange point rather than send it to the correct peer - seems much more robust to me, although you might end up with heavy packet replication :-) -- Simon Leinen simon@babar.switch.ch SWITCH http://www.switch.ch/misc/leinen/ Computers hate being anthropomorphized.
On Fri, Jun 01, 2001 at 07:39:48AM -0400, Alex Rubenstein wrote:
Perhaps I am using this feature wrong, but I don't think so.
This morning, I am trying to get mac-address accounting working on a 7507MX/RSP8/12.0.17S/GEIP+ running ISL, to indentify large peers off an ethernet peering fabric.
I've done 'ip accounting mac-address out'. I then wait.
Then, I:
core1.nyc#sho int g0/0/0 mac-accounting GigabitEthernet0/0/0 to external peers and customers Output (475 free) 0001.64da.bc00(3 ): 2 packets, 179 bytes, last: 3036ms ago 0004.de2b.e41c(9 ): 1 packets, 99 bytes, last: 3036ms ago 00e0.52a6.1f00(11 ): 1 packets, 99 bytes, last: 3036ms ago 0100.0c00.0000(13 ): 57198 packets, 37155973 bytes, last: 388ms ago 0030.7bee.fc54(13 ): 2 packets, 218 bytes, last: 2836ms ago
All of the mac-addresses listed in this 'sho' are valid, except for '0100.0c00.0000', which doesn't exist:
core1.nyc#sho arp | inc 0100 core1.nyc#
All the others are valid, yet they are way, and I mean *way* under the amounts that I know I am sending to that peer.
Any clues? I've searched CCO/Bug Toolkit, I don't see anything relevant.
I have a similar problem with 7206VXR/PA-FE-TX/12.1(5)/802.1q, DDTS CSCdt84869 opened. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: FreeBSD committer @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them.
participants (3)
-
Alex Rubenstein -
Jesper Skriver -
Simon Leinen