mac-address accounting

Mailman List Mirror (Read Only)
1

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.

2

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 :slight_smile:

3

I have a similar problem with 7206VXR/PA-FE-TX/12.1(5)/802.1q,
DDTS CSCdt84869 opened.

/Jesper