[c-nsp] Best practice - Core vs Access Router

[Phil Mayers]

On 09/02/10 13:45, Andy B. wrote:
>> Are these receive addresses in the router or transit?
>>
>> sh mls cef lookup x.x.160.112
>> sh mls cef lookup x.x.160.112 detail
>> <from output A:123>
>> sh mls cef adjacency entry 123 detail
>>
>
> #show buffers input-interface te9/1 header
>
> Buffer information for Small buffer at 0x50070DC8
>    data_area 0x80667C4, refcount 1, next 0x45475F58, flags 0x280
>    linktype 7 (IP), enctype 1 (ARPA), encsize 14, rxtype 1
>    if_input 0x4646B618 (TenGigabitEthernet9/1), if_output 0x0 (None)
>    inputtime 47w4d (elapsed 00:00:09.252)
>    outputtime 47w4d (elapsed 00:03:54.772), oqnumber 65535
>    datagramstart 0x806683A, datagramsize 62, maximum size 308
>    mac_start 0x806683A, addr_start 0x806683A, info_start 0x0
>    network_start 0x8066848, transport_start 0x8066878, caller_pc 0x4187C1F0
>
>    source: x.x.224.116, destination: y.y.176.97, id: 0x79FD, ttl: 121,
>    TOS: 0 prot: 6, source port 2844, destination port 445
>
> x.x = outside

Ok, so this is an inbound TCP packet to port 445, for a host which isn't 
in the ARP table, hence the glean:

> #sh mls cef lookup y.y.176.97
>
> Codes: decap - Decapsulation, + - Push Label
> Index  Prefix              Adjacency
> 20304  y.y.176.0/24    glean

Probably random malware/virus scanning.

Obviously the CPU will handle gleans (things which need an ARP lookup). 
As has been pointed out, you can enable the "glean" rate limiter but two 
points to bear in mind:

  1. It's box-global and there's no per-interface round-robin or 
anything. Basically you're telling it "only ever send me 200 packets 
which need an ARP lookup per second" and if some bad person on the 
internet sends you 201, they can crowd out legitimate local traffic (the 
glean rate-limiter should really be per input-SVI. Sigh...)

  2. It seems a bit unlikely that you'll suddenly get 5x more glean 
traffic at the exact peak of your forwarding rate, so this might be just 
random background traffic.


Personally I would use a SPAN or (E)RSPAN session monitoring the CPU 
during an outage to see what's actually hitting the CPU:

http://cisco.cluepon.net/index.php/6500_SPAN_the_RP

...this is a lot easier under later IOS, but can be done under SXF. Why 
guess what's hitting the CPU when you can *know*?