On Sun, Mar 14, 2010 at 01:18:39PM +0000, chrisccnpsp...@gmail.com wrote: > One thing I would check for first is unicast flooding. It sounds like > the backup router is flooding all traffic as it doesn't have any arp/mac > tables created for traffic that comes ingress to it. Would be hard to > pinpoint the issue unless you can provide some traffic flow stats. > > Unicast flooding is a common problem with active/backup switching > environments. If this is the case we can work on modifying the mac > and arp timers to resolve it. > > Hope this helps
Thanks, you described my problem mostly exactly, with the only difference: actually my backup router had correct arp table, with default arp aging-time of 20min, but mac-table-aging-time on second core switch was (by default) just 300sec, so in five minutes after backup router passive-learned some arp entry switch had to flood traffic in unknown-unicast mode, thus affecting only ports on "even" access-switches. Thanks again. > Sent via BlackBerry by AT&T > > -----Original Message----- > From: Alexandre Snarskii <s...@snar.spb.ru> > Date: Sun, 14 Mar 2010 14:25:49 > To: Juniper-NSP Mailing list<juniper-nsp@puck.nether.net> > Subject: [j-nsp] mysterious microbursts ? > > > Hi! > > During routine maintenance on my ex-3200 switches I found that > some devices, connected with 100mbit/full-duplex observe minor > packet loss. Well, there is nothing too unexpected, you can > see it mostly every time when traffic enters switch using 1ge (2x1ge > aggregate in my case) link and exits using 100mbit, switch ports > just do not have enough buffer space to handle bursts well, but... > That's where the strangeness begins: > a) these 100mbit ports used to connect VoIP devices handling RTP > traffic, so there should be no bursts at all. > b) there are more than 30 such devices in my network, and I see > that loss only on half of them - on that half that is connected > to even-numbered switches, there are no packet loss on devices > connected to odd-numbered ones. > > Logical topology is just "a vlan connected to a router (two routers > in VRRP master/slave scenario)", physical is classic ring (some rings > actually, each odd-numbered access switch connected to coresw1, > even-numbered - to coresw2): > > router1 router2(backup, no traffic right now) > | | > coresw1 ================ coresw2 > | | > | | > accsw1 -------- x ------ accsw2 > > link between core switches is 10ge, links core-access and access-access > is 2x ge aggregated ethernet, access-access links are blocked by STP. > Switches is ex3200-24t(core) and ex3200-48t(access), running 9.3R4.4. > > Well, these losses is about 0.1% and I can live with that, but > I'd like to have any idea on why it happens only on half of > devices, and I don't have one :( > Any clue ? > > Example interface with errors: > > Physical interface: ge-0/0/26, Enabled, Physical link is Up > Interface index: 165, SNMP ifIndex: 174, Generation: 168 > Link-level type: Ethernet, MTU: 1514, Speed: 100mbps, Duplex: Full-Duplex, > MAC-REWRITE Error: None, > Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled, > Auto-negotiation: Disabled, > Remote fault: Online > Device flags : Present Running > Interface flags: SNMP-Traps Internal: 0x0 > Link flags : None > CoS queues : 8 supported, 8 maximum usable queues > Hold-times : Up 0 ms, Down 0 ms > Current address: 00:19:e2:53:66:9a, Hardware address: 00:19:e2:53:66:9a > Last flapped : 2010-03-05 04:36:34 PST (1w1d 22:21 ago) > Statistics last cleared: 2010-03-11 06:44:54 PST (2d 20:13 ago) > Traffic statistics: > Input bytes : 88312256790 0 bps > Output bytes : 88616684644 5984 bps > Input packets: 443797702 0 pps > Output packets: 412072442 10 pps > IPv6 transit statistics: > Input bytes : 0 > Output bytes : 0 > Input packets: 0 > Output packets: 0 > Input errors: > Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 0, L3 > incompletes: 0, L2 channel errors: 0, > L2 mismatch timeouts: 0, FIFO errors: 0, Resource errors: 0 > Output errors: > Carrier transitions: 0, Errors: 0, Drops: 0, Collisions: 0, Aged packets: > 0, FIFO errors: 0, HS link CRC errors: 0, > MTU errors: 0, Resource errors: 0 > Egress queues: 8 supported, 4 in use > Queue counters: Queued packets Transmitted packets Dropped > packets > 0 best-effort 0 411934501 > 454642 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > 1 assured-forw 0 0 > 0 > 5 expedited-fo 0 0 > 0 > 7 network-cont 0 137336 > 0 > Active alarms : None > Active defects : None > MAC statistics: Receive Transmit > Total octets 88312256790 88616684644 > Total packets 443797702 412072442 > Unicast packets 443796941 410096125 > Broadcast packets 761 447035 > Multicast packets 0 1529282 > CRC/Align errors 0 0 > FIFO errors 0 0 > MAC control frames 0 0 > MAC pause frames 0 0 > Oversized frames 0 > Jabber frames 0 > Fragment frames 0 > Code violations 0 > Autonegotiation information: > Negotiation status: Incomplete > Packet Forwarding Engine configuration: > Destination slot: 0 > Direction : Output > CoS transmit queue Bandwidth Buffer Priority > Limit > % bps % usec > 0 best-effort 95 95000000 95 NA low > none > 7 network-control 5 5000000 5 NA low > none > > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp