Overview

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-addresscommand 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

6-16 Configuring the Border Gateway Protocol

Page 164
Image 164
Enterasys Networks X-PeditionTM manual Synchronization, Address Aggregation, Route Flap Dampening