[c-nsp] Unicast flooding?

Frank Bulk - iName.com frnkblk at iname.com
Wed Jan 13 09:48:18 EST 2010


I agree, I have some good evidence.  I'm not against upgrading if that will
resolve the issue.

Frank

> -----Original Message-----
> From: Pavel Skovajsa [mailto:pavel.skovajsa at gmail.com]
> Sent: Wednesday, January 13, 2010 3:43 AM
> To: frnkblk at iname.com
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Unicast flooding?
> 
> Hello Frank,
> 
> Does not sound really healthy - if you have gathered good evidence
> this is a good candidate for TAC. Anyway - you should probably upgrade
> to something other then SRB4 as TAC will tell you probably the same
> thing....
> 
> -pavel skovajsa
> 
> On Wed, Jan 13, 2010 at 7:02 AM, Frank Bulk <frnkblk at iname.com> wrote:
> > We've been seeing some strange behavior on our 7609-S running
> 12.2(33r)SRB4.
> > We have a VLAN (with four /24s) configured on three ports across two
> > 10/100/1000 blades facing some FTTH transport equipment.
> >
> > Customers hanging off the FTTH equipment on the third port are
> complaining
> > that several times per day they lose internet access.  We've been
> able to
> > correlate their complaints with failed ping attempts from our
> workstations
> > and the 7609-S to their public IPs.  What's interesting is that it's
> not all
> > the traffic, and of the 4 IPs we are tracking, two of which are on
> separate
> > /24s, the outages happen within the same /24.  At the same time,
> while using
> > Wireshark, I can see one of the Cisco interfaces sending out 1 to 2
> Mbps of
> > traffic that should be going to one of the other two Ethernet
> interfaces.
> > This is happening about a dozen times per day for 4 to 6 minutes at a
> time.
> >
> >
> > While the event is occurring I have verified the ARP and CAM entry.
>  The CAM
> > entry is associated with one of the first two Ethernet interfaces,
> not the
> > third.  I can clear the ARP and CAM entry from the CLI and they are
> > re-learned with the same information, yet the traffic continues to
> egress
> > the wrong Ethernet port.
> >
> > I've set the ARP timeout to 4 minutes so that it's less than the CAM
> table's
> > default configuration of 5 minutes, but there was no improvement.
>  One more
> > observation -- the errant port is the root of the bridge.
> >
> > Any ideas why the 7609 would be sending traffic out an Ethernet port
> to a
> > device that the CAM table says is on a different Ethernet port?
> >
> > Frank
> >
> >
> > interface Vlan10
> >  description FTTH network
> >  ip dhcp relay information trusted
> >  ip dhcp relay information option-insert none
> >  ip dhcp relay information policy-action keep
> >  ip address 67.22.a.1 255.255.255.0 secondary
> >  ip address 67.22.b.1 255.255.255.0 secondary
> >  ip address 67.22.c.1 255.255.255.0 secondary
> >  ip address 67.22.d.1 255.255.255.0
> >  ip helper-address e.f.g.h
> >  no ip redirects
> >  arp timeout 300
> > end
> >
> > interface GigabitEthernet1/29 (and 3/39 and 3/45)
> >  switchport
> >  switchport trunk encapsulation dot1q
> >  switchport trunk allowed vlan 10
> >  switchport mode trunk
> >  switchport nonegotiate
> >  load-interval 30
> >  spanning-tree portfast trunk
> > end
> >
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >



More information about the cisco-nsp mailing list