Enterasys Networks Security Router X-PeditionTM - Manual (Page 164)

Overview
6-16 Configuring the Border Gateway Protocol
Synchronization
When an AS provides transit service to other ASs and if there are non-BGP routers in the AS,
transit traffic might be dropped if the intermediate non-BGP routers have not learned routes for
that traffic via an IGP. BGP synchronization, which is enabled on the XSR by default, stipulates
that a BGP router should not advertise to external neighbors destinations learned from IBGP
neighbors unless those destinations are also known via an IGP. If a router is so informed, it
assumes that the route has already been propagated inside the AS, and internal reachability is
guaranteed. Synchronization can be disabled with the
no synchronization command if either of
the following conditions pertain:
• Your AS does not pass traffic from one AS to another AS.
• All the transit routers in your AS run BGP.
Address Aggregation
BGP routing tables are likely to include thousands of entries so maintaining and updating a large
table can prove processor intensive. BGP counters this problem by enabling specific networks to
be consolidated into aggregate routes, thus reducing the size of the BGP routing table.
They can be configured either by redistributing an aggregate route into BGP or by using the
conditional aggregation options described below. The XSR adds an aggregate address to the BGP
table if there is at least one more specific entry there. The
aggregate-address command adds an
aggregate address to the routing table with the following options:
• Adds an aggregate entry to the BGP routing table: <address><mask>
• Generates AS set path data: [as-set]
• Advertises summary addresses only: [summary-only]
• Creates an aggregate reflecting values configured in the route map: [advertise-map]
• Creates an aggregate with route map parameters: [attribute-map]
Route Flap Dampening
Routes flap or oscillate when a route is advertised and then withdrawn, or a route is withdrawn
and re-advertised in rapid succession. EBGP flapping causes global churn in the routing table,
because as the flap ripples across the Internet each router must process the routing data change.
IBGP flapping engenders irregular traffic flow and reachability problems within the local AS, and
can affect EBGP stability if IBGP routes are advertised to EBGP peers. On the XSR, rapid flapping
can cost significant CPU cycles spent on processing the routing updates. From the network
perspective, route flapping usually indicates a problem, such as a circuit going up and down, or
fatal recurring errors between BGP peers.
Route flap dampening is a reactive measure available to prevent route flaps from propagating
across an internetwork by selectively suppressing route advertisement. Based on the premise that
past can suggest future behavior, dampening penalizes malfunctioning routes and advertises
stable routes with minimal delay. This does not preclude the likelihood of some route flapping
though, since updates reflect normally occurring changes on the Internet. So, reasonable routing
changes should not be penalized; that is, one flap within a few minutes does not necessarily
indicate a problem, but five flaps within a few minutes probably does.
When you enable this functionality with the bgp dampening command, the XSR collects statistics
about the prefix announcements and withdrawals. If a threshold of the number of pairs of
withdrawals/announcements (flaps) is exceeded in a given period (the cutoff threshold), the