[c-nsp] Bug ID CSCdy72539 For GRE Tunneling on 6500 PFC3B

[Phil Mayers]

Dale W. Carder wrote:
> On Dec 8, 2006, at 5:59 AM, Gert Doering wrote:
>> On Fri, Dec 08, 2006 at 08:08:43AM +0100, Asbjorn Hojmark - Lists  
>> wrote:
>>> I would do a sniffer trace of the data going to the CPU. I you
>>> haven't done that before, I suggest you open a TAC case.
>> Being curious, but not willing to open a TAC case for *that* - is  
>> there
>> public documentation available how to monitor "punt to CPU" traffic?
> 
> It's extremely useful for troubleshooting high cpu load, and for
> profiling traffic to set up CoPP.  This procedure is not widely known
> probably for a good reason, and possibly dangerous.  Use at your own  
> risk:

This is an awesomely useful procedure. My understanding is that in fact 
the mirroring is performed in hardware by configuring the replication 
chip to mirror the internal gigE port that faces the RP. So in principle 
it ought to be relatively safe. As Dale says though - own risk...

I've found all kinds of junk on our network with this.

Something else to note - you can use (I have successfully used on many 
occasions) an erspan (span over GRE) session as the target, allowing 
remote mirroring.

(I wrote a little python erspan->pcap util for this)

> 
> 1) Set up a span session with a source port that is down:
> 
> monitor session 2 source interface Fa8/24      (down)
> monitor session 2 destination interface Gi6/9  (sniffer)
> 
> 2) Then on the switch processor via remote login switch, configure

For those unfamiliar, that would be "attach X" where X is the slot of 
the active sup.

> test monitor session 2 add rp-inband tx

You can also mirror the SP if you've having a layer2 protocol issue.

Also, do NOT forget to disable the RP/SP mirroring before disabling the 
monitor session.