[c-nsp] ASR9001, 4.3.4sp6, MAC-Accounting ignoring certain peers?

[Gert Doering]

Hi,

until about 15 minutes ago, I was a happy camper, and enjoying the
benefits of MAC accounting on one of our ASR9001's - connected to DECIX,
shuffling packets in and out to quite a number of peers (4.3.4sp6).

Expected results matched about what I thought the "top 20" peers would
be, so life was good.

Now, we turned up a new customer who is sending quite a bit of traffic
towards one peer - and it's *outgoing*, so I am very sure I know which
MAC the traffic is going to.  "show cef" agrees with me:

RP/0/RSP0/CPU0:Cisco#show cef x.x.x.x
Wed Mar  9 21:01:06.593 MET
x.x.x.0/y version 418032052, internal 0x14000001 (ptr 0xa3119ea8) [1], 0x0 (0x0), 0x0 (0x0)
 Updated Mar  9 06:04:50.373
 Prefix Len 16, traffic index 0, precedence n/a, priority 4
 BGP Attribute: id: 0x18f4, Local id: 0xd700, Origin AS: 24940, Next Hop AS: 24940 
 
   via 80.81.192.164, 3 dependencies, recursive, bgp-ext [flags 0x6020]
    path-idx 0 [0xa16335cc 0x0]
    next hop 80.81.192.164 via 80.81.192.164/32

RP/0/RSP0/CPU0:Cisco#sh arp 80.81.192.164
Wed Mar  9 21:01:46.974 MET

-------------------------------------------------------------------------------
0/0/CPU0
-------------------------------------------------------------------------------
Address         Age        Hardware Addr   State      Type  Interface
80.81.192.164   00:00:11   54e0.32bb.f9c8  Dynamic    ARPA  TenGigE0/0/2/3


but MAC accounting claims "no, there is no traffic to that peer" (even
if I ping it...):

RP/0/RSP0/CPU0:Cisco-F#sh mac-accounting ten0/0/2/3 | inc 54e0.32
Wed Mar  9 21:02:28.568 MET
    54e0.327e.2fc2:  86955 packets, 43604038 bytes
    54e0.32b8.aec5:  18 packets, 1508 bytes
    54e0.32b9.26c5:  18 packets, 1500 bytes
    54e0.32c6.47c1:  127 packets, 10874 bytes
    54e0.327e.2fc2:  112779 packets, 132892839 bytes
    54e0.32b8.aec5:  8 packets, 644 bytes
    54e0.32b9.26c5:  7 packets, 558 bytes
    54e0.32c6.47c1:  8 packets, 644 bytes
    54e0.32cd.dd68:  1 packets, 42 bytes
    54e0.32cf.7cf0:  1 packets, 42 bytes

as you can see, MAC accounting is working, and is accumulating lots of
traffic for some addresses, and just a bit of random noise from others
(there's many routers we do not peer with, but of course we see their
ARP requests etc.) - so why isn't it picking traffic for 54e0.32bb.f9c8?

Tried the usual approaches - "clear mac-accounting", "clear arp-cache",
no change.

Someone mentioned a few months ago that there supposedly is a limit of
512 peer MAC addresses - but the list of addresses that the box *is*
counting traffic for is around 400 right now, which is not your typical
"magic number" for a computer...  (398 in, 420 out).


Documentation on CCO is somewhat sparse - "this is how you turn it on,
this is how you can show the counters, and that is how you clear them" - 
but I can't find anything in hardware restrictions, tuning, etc.  (I did
find one document *for ASR9000* that claims "This feature ... supports
CEF, dCEF, flow and optimum switching"... *cough*)

So - anyone of you using this?  Should this work?  Where are the caveats?

(Even more interesting: said peer seems to have replaced their router
at Dec 3, 2015 - a new mac address in my saved arp cache stats, and since
then, gone from my radar...)

gert

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 291 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20160309/49e1d5b5/attachment.sig>