Debug netdr

Unanswered Question
Aug 17th, 2010

I am completely lost on this one. We have a 6506-E w/ dual sup720B

where I work and it started taking massive cpu hits over the past couple

of weeks. After utilizing the debug netdr command I was able to narrow

the culprit down to the ghost server. Funny thing about this is that the

current ghosting was being done completely local. When I say that I mean

that the ghost server connects to a 2950 which connects back to a 4506

distribution switch. The 6506 is two hops down stream from the 4506 and

the traffic should have never gone to it because the computer being

ghosted hangs off of another 2950 coming off of the 4506 distribution switch.

I am by no means a multicast guru and am finding myself in a pickle here.

Below is a snippet of output from netdr with the src IP changed to a different

IP address.

------- dump of incoming inband packet -------
interface Gi1/3, routine draco2_process_rx_packet_inline
dbus info: src_vlan 0x3FA(1018), src_indx 0x2(2), len 0x5D2(1490)
  bpdu 0, index_dir 0, flood 1, dont_lrn 0, dest_indx 0x43FA(17402)
  80020400 03FA0000 00020005 D2000000 00110510 0E000040 00000008 43FA0000
mistral hdr: req_token 0x0(0), src_index 0x2(2), rx_offset 0x76(118)
  requeue 0, obl_pkt 0, vlan 0x3FA(1018)
destmac 01.00.5E.4D.0C.7C, srcmac 00.16.9C.EA.BE.40, protocol 0800
protocol ip: version 0x04, hlen 0x05, tos 0x00, totlen 1472, identifier 31376
  df 0, mf 0, fo 0, ttl 13, src, dst
    udp src 4525, dst 7777 len 1452 checksum 0x69C0

I can't seem to find to much out there regarding the netdr command which

kind of stinks. One thing I am curious about though is the flood parameter

which has a 1 next to it. If anyone could provide some insight I would greatly

appreciate it.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
belovell Mon, 08/23/2010 - 08:01

Very little info to go on but...

I wouldn't pay attention to the flood bit as depending on the port config and other thingss it could be normal.

I think the key here is that you said the mcast should never get to the 6500. If this is the case it is likely being RPF droped. When RPF dropping on 6500 we "leak" some packets up to the CPU. If you hit it hard enough with enough groups then the "leaked" packets can start to affect the CPU.



This Discussion