[isp-bgp] Re: Suggested solution to prevent my prefixes from being suppressed

[James <haesu@...>]

On Tue, Oct 26, 2004 at 08:08:39AM -0500, Pete Templin wrote:
> 
> Several suggestions:
> 
> 1) Why are your BGP sessions flapping?  BGP packets are normally 
> precedence 6, and should in many cases pass through nearly any saturated 
> link.  Determining why they're flapping is probably a good thing to 
> research first.

Pretty hard to come through when upstream router is choked and dropping massive packets
on the downstream interface. Some DDoS attacks also set precedence to higher prec, and its
really hard to keep a tcp session alive on a link that's only capable of say.. for
exapmle.. ~200kpps, while the attack is reaching over 1Mpps..

-J

> 
> 2) Adjust BGP timers to delay the interval until the session is 
> restored.  It's commonly believed that keeping your prefix DOWN on a 
> given BGP session for perhaps several minutes is necessary to minimize 
> dampening.  Since the original flap withdrawal won't propagate through 
> any single network at the same exact rate, having one network 
> withdrawing your downward flap while another network is announcing your 
> upward flap can greatly influence route churn and get you dampened in a 
> hurry.
> 
> 3) Check EVERY possible attribute on your announcements to make sure 
> they're as identical as your routing policy allows.  I had a customer 
> add a second router to his network.  Each router was creating an 
> aggregate route to be announced to his two upstreams, but unbeknownst to 
> him it was including an "(aggregated by x.x.x.x)" field that reflected 
> the router's ID.  As his prefix was withdrawn across the Internet, that 
> field was oscillating between the values for R1 and R2, causing very 
> high flap count.  Removing that attribute from his announcements gave 
> him clean redundancy once again, along with the benefit of redundant 
> routers.
> 
> 4) You may want to consider disabling fast external failover if it's 
> enabled.  The loss of instant session reset in the event of link failure 
> may be less than the gain of stable sessions and advertised prefixes.
> 
> pt
> 
-- 
James Jun                                            TowardEX Technologies, Inc.
Technical Lead                       IPv4 and Native IPv6 Colocation, Bandwidth,
james@...             and Web Hosting Services in the Metro Boston area
cell: 1(978)-394-2867           web: http://www.towardex.com , noc: www.twdx.net

        _____________________________________________________

        ** ISPCON Fall 2004 - Santa Clara Convention Center **
         ** The ISP and WISP event - http://www.ispcon.com **
** Fill your brain.  Meet the people.  Join the industry gathering. **
       ________________________________________________________






To unsubscribe via postal mail, please contact us at:
Jupitermedia Corp.
Attn: Discussion List Management
475 Park Avenue South
New York, NY 10016

Please include the email address which you have been contacted with.