Another time I saw this on 7200's running very old code when you enabled
multicast. The PA was put into promiscuous mode, and would think that
everything was destined to it and attempt to act accordingly.
David
> -----Original Message-----
> From: Steve Francis [mailto:steve@expertcity.com]
> Sent: Sunday, December 02, 2001 11:32 AM
> To: Jim Warner
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: packet duplication
>
>
> Hi Jim.
>
> Looks liekl calren is still being Interesting.
> I've seen this before - on two different platforms. Neither
> of which were
> the GSR that this seems to be from the name.
>
> I've seen a 7206 with 12.1T, 12.1 and 12.2 amplify packets about 200
> times. You could instantly fix the problem by disabling CEF. (The
> problem does not occur in the 12.0S train.) Reenable CEF, and the
> amplifcation resumes - but not straight away, and not for all IP
> addresses transiting the router, and different IP addresses being
> affected after different periods of time.
>
> I've also seen 6500's MSFC II's with current code amplify
> packets about 4
> times (as you see), in similar circumstances. No option to
> disable CEF
> there.
>
> However, both occurrences also had HSRP running, and removing
> that also
> seemed to fix it.
>
> (In first case, cisco saw it happen on my routers, but could not
> reproduce in the lab, and basically gave up. I was OK with that as I
> found it didn't occur in 12.0S, and I changed things so I
> didn't need the
> features that were preventing me using that code in first place.
> In second case -their still stumped and looking.)
>
> Is HSRP involved at all here?
>
> Cheers.
> Steve Francis (ex-UCSB.)
>
>
> Jim Warner wrote:
>
> > When I ping to a particular router my reply packets are
> > getting duplicated. It looks like:
> >
> > bash-2.03$ ping 137.164.12.33
> > PING 137.164.12.33 (137.164.12.33): 56 data bytes
> > 64 bytes from 137.164.12.33: icmp_seq=0 ttl=250 time=24.924 ms
> > 64 bytes from 137.164.12.33: icmp_seq=0 ttl=250 time=25.013
> ms (DUP!)
> > 64 bytes from 137.164.12.33: icmp_seq=0 ttl=248 time=25.247
> ms (DUP!)
> > 64 bytes from 137.164.12.33: icmp_seq=0 ttl=248 time=25.698
> ms (DUP!)
> > 64 bytes from 137.164.12.33: icmp_seq=1 ttl=250 time=24.084 ms
> > 64 bytes from 137.164.12.33: icmp_seq=1 ttl=250 time=24.594
> ms (DUP!)
> > 64 bytes from 137.164.12.33: icmp_seq=1 ttl=248 time=24.825
> ms (DUP!)
> > 64 bytes from 137.164.12.33: icmp_seq=1 ttl=248 time=25.030
> ms (DUP!)
> > 64 bytes from 137.164.12.33: icmp_seq=2 ttl=250 time=24.330 ms
> > 64 bytes from 137.164.12.33: icmp_seq=2 ttl=250 time=24.544
> ms (DUP!)
> > 64 bytes from 137.164.12.33: icmp_seq=2 ttl=248 time=24.750
> ms (DUP!)
> > 64 bytes from 137.164.12.33: icmp_seq=2 ttl=248 time=25.173
> ms (DUP!)
> >
> > Not shown here, but this effect happens when I pass through this
> > router. Anything beyond it is replicated.
> >
> > I have seen routing loops cause things that are similar, but
> > not the same as this. But here the duplication is always the
> > same. I think that my packets to the router are being replicated,
> > and then each of the replies is getting replicated -- which is
> > why I see four responses to everything I send.
> >
> > I am curious to hear what sorts of pathologies might result in
> > this kind of packet copying. There is ATM in the path. Could
> > it be the culprit? I am pretty sure that the equipment doing the
> > packet copying is made by Cisco. The same way that I can't imagine
> > that a bad packet would cause a fan to fail, I can't imagine how a
> > packet could be copied a fixed number of times.
> >
> > I know this would be easier if there was a map of the topology.
> > Is anyone willing to speculate without one?
> >
> > Thanks. -jim warner, UC santa cruz
>
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:25 EDT