Other BGP features
Route Dampening
Routes addtiction and deletion in case of flappering links can be a problem if appliedto the worldwide scale: if a link flaps in a remote AS location it can cause instability in corvengence of BGP world wide and consume time / BGP resources in multiple AS. BGP Dampering (RFC based) is useful to limit this, containing flapping routes within the AS boundary.
Routers running dapering penalise routes that are flappering. The penalisation scheme is based on thresholds for suppression (suppress limit) and re-utilization (reuse limit). Every flap is penalised of 1000 penality points, and the decay system is exponential (keeps a router longer in suppression if it frequently flaps).
Command: bgp dampering {half-life reuse suppress max-suppress-time} {route-map <RM>}
Example (with the defaults):
router bgp 300
bgp dampering 
15 750 2000 60
Useful:
clear ip bgp A.B.C.D flap-statistics
clear ip bgp dampering
clear ip bgp dampened-paths
clear ip bgp flap-statistics
BGP Link Bandwidth (Extended Community):
Unequal cost load balancing over links with unequal bandwidth was not possible in BGP before the BGP Link Bandwidth feature was introduced. The BGP Link Bandwidth features enables unequal cost load balancing over multiple links on top of the BGP multipath (“maximum-paths”) feature.
=> 1. Configure Multipath
1720a(config)router bgp 400
1720a(config-router)maximum-paths 3
1720a# sh ip bgp 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 17
Paths: (3 available, best 3, table Default-IP-Routing-Table)
Multipath: eBGP
Flag: 0x800
Advertised to peer-groups:
eBGP_to_AS100
Advertised to non peer-group peers:
192.168.0.1
100 300 200
192.168.103.2 from 192.168.103.2 (192.168.0.6)
Origin IGP, localpref 100, valid, external, multipath
100 300 200
192.168.104.2 from 192.168.104.254 (192.168.0.5)
Origin IGP, localpref 100, valid, external, multipath
100 300 200
192.168.102.2 from 192.168.102.2 (192.168.0.3)
Origin IGP, localpref 100, valid, external, multipath, best
1720a# sh ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via “bgp 400”, distance 20, metric 0, candidate default path
Tag 100, type external
Last update from 192.168.102.2 00:00:21 ago
Routing Descriptor Blocks:
192.168.103.2, from 192.168.103.2, 00:00:21 ago
Route metric is 0, traffic share count is 1
AS Hops 3
192.168.104.2, from 192.168.104.254, 00:00:21 ago
Route metric is 0, traffic share count is 1
AS Hops 3
192.168.102.2, from 192.168.102.2, 00:00:21 ago
Route metric is 0, traffic share count is 1
AS Hops 3
=> 1. Configure BGP Link Bandwidth announcements.
The BGP Link Bandwidth feature allows BGP to distribute traffic proportionally to the bandwidth of each external link. The link bandwidth extended community is used to indicate the preference of an autonomous system exit link in terms of bandwidth. Remember:
– The “neighbor dmzlink-bw” command configures the peer to advertise and accept the available bandwith to/from eBGP peers.
– The “bgp dmzlink-bw” command allows a peer to use the link bandwidth extended community as advertised by the remote peer.
– The link bandwidth extended community attribute is propagated to BGP peers only if extended community exchange is enabled with the “neighbor send-community” command.
– The BW values are depending on the interfaces “bandwidth” commands.
1720abgc
router bgp 400
no synchronization
bgp router-id 192.168.0.2
bgp log-neighbor-changes
bgp dmzlink-bw <<<<<<<<
timers bgp 30 90
neighbor eBGP_to_AS100 peer-group
neighbor eBGP_to_AS100 remote-as 100
neighbor eBGP_to_AS100 send-community
neighbor eBGP_to_AS100 dmzlink-bw <<<<<<<<
neighbor 192.168.0.1 remote-as 400
neighbor 192.168.0.1 update-source Loopback999
neighbor 192.168.102.2 peer-group eBGP_to_AS100
neighbor 192.168.103.2 peer-group eBGP_to_AS100
neighbor 192.168.104.254 peer-group eBGP_to_AS100
maximum-paths 3 <<<<<<<<
no auto-summary
1600abgc
router bgp 65002
no synchronization
bgp router-id 192.168.0.6
bgp log-neighbor-changes
bgp confederation identifier 100
bgp confederation peers 65001 65003
bgp bestpath med missing-as-worst
bgp dmzlink-bw
timers bgp 30 90
neighbor eBGP_to_AS400 peer-group
neighbor eBGP_to_AS400 remote-as 400
neighbor eBGP_to_AS400 send-community both
neighbor 192.168.103.1 peer-group eBGP_to_AS400
neighbor 192.168.103.1 dmzlink-bw
neighbor 192.168.105.2 remote-as 65001
neighbor 192.168.105.2 route-map SET_PREF in
neighbor 192.168.107.1 peer-group eBGP_to_AS400
1600bbgc
router bgp 65001
no synchronization
bgp router-id 192.168.0.5
bgp log-neighbor-changes
bgp confederation identifier 100
bgp confederation peers 65002 65003
bgp bestpath med missing-as-worst
bgp dmzlink-bw
timers bgp 30 90
neighbor 192.168.104.1 remote-as 400
neighbor 192.168.104.1 weight 1000
neighbor 192.168.104.1 send-community both
neighbor 192.168.104.1 dmzlink-bw
neighbor 192.168.104.2 remote-as 65003
neighbor 192.168.105.1 remote-as 65002
neighbor 192.168.109.2 remote-as 200
1720bbgc
router bgp 65003
no synchronization
bgp router-id 192.168.0.3
bgp log-neighbor-changes
bgp confederation identifier 100
bgp confederation peers 65001 65002
bgp bestpath med missing-as-worst
bgp dmzlink-bw
timers bgp 30 90
neighbor 192.168.102.1 remote-as 400
neighbor 192.168.102.1 send-community
neighbor 192.168.104.254 remote-as 65001
neighbor 192.168.106.2 remote-as 300
no auto-summary
1720a# sh ip bgp 0.0.0.0/0
BGP routing table entry for 0.0.0.0/0, version 26
Paths: (3 available, best 3, table Default-IP-Routing-Table)
Multipath: eBGP
Flag: 0x800
Advertised to peer-groups:
eBGP_to_AS100
Advertised to non peer-group peers:
192.168.0.1
100 300 200
192.168.103.2 from 192.168.103.2 (192.168.0.6)
Origin IGP, localpref 100, valid, external, multipath
DMZ-Link Bw 1250 kbytes
100 300 200
192.168.104.2 from 192.168.104.254 (192.168.0.5)
Origin IGP, localpref 100, valid, external, multipath
DMZ-Link Bw 8 kbytes
100 300 200
192.168.102.2 from 192.168.102.2 (192.168.0.3)
Origin IGP, localpref 100, valid, external, multipath, best
DMZ-Link Bw 12500 kbytes
=> Note: the BW values depend on the BW command
1720a# sh int f0 | in BW
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, => 12500 kbytes 8 = 100000 kbits
1720a# sh int e0 | in BW
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, => 1250 kbytes 8 = 10000 kbits
1720a# sh int s0 | in BW
MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, => 8 kbytes 8 = 6400 kbits
Maximum Prefix Limit and Restart Session After Max-Prefix Limit reached.
Te command allows the configuration of a maximum number of prefixes that a BGP router is allowed to receive from a peer. It adds another mechanism (in addition to distribute lists, filter lists, and route maps) to limit and control prefixes received from a peer.
=> If no keyword is added, when the number of received prefixes exceeds the maximum number configured, the router disables the peering session (by default).
=> If the restart keyword is configured, the router will automatically reestablish the peering session at the configured time interval.
=> If the warning-only keyword is configured, the router, instead of tearing down the session, sends a log message. If the peer is terminated, the peer stays down until the clear ip bgp command is issued.
1720a# sh ip bgp summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.0.1 4 400 297 325 29 0 0 02:21:42 1
1720a(config-router)neighbor 192.168.0.1 maximum-prefix 3 ?
<1-100> Threshold value (%) at which to generate a warning msg
restart Reestart bgp connection after limit is exceeded
warning-only Only give warning message when limit is exceeded
<cr>
1720a(config-router)neighbor 192.168.0.1 maximum-prefix 3 warning-only
.Nov 13 14:14:30: %BGP-4-MAXPFX: No. of prefix received from 192.168.0.1 (afi 0) reaches 3, max 3
1720a# sh ip bgp summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.0.1 4 400 315 336 31 0 0 02:24:56 3
BGP Cost Community (modifies Path Selection, instead of IGP metric)
The cost extended community attribute. The cost community is a [non-transitive extended community] attribute that is passed to internal BGP (iBGP) and confederation peers but NOT to external BGP (eBGP) peers. The cost community feature allows you to customize the local route preference and influence the best path selection process by assigning cost values to specific routes.
The cost community attribute is applied to internal routes by configuring the “set extcommunity cost” command in a route map. The neighbor send-community command is naturally required at all peers. The following commands can be used to apply the route map setting cost community:
• aggregate-address
• neighbor default-originate route-map {in | out}
• neighbor route-map
• network route-map
• redistribute route-map
=> How the BGP Cost Community Influences the Best Path Selection Process
The cost community attribute influences the BGP best path selection process at the point of insertion (POI) (that is after the type of advertisement – iBGP/EBGP – and before the IGP metric. By default, the POI follows the IGP metric comparison, but it can be set to use the Cost Community.
If the Cost Community is enabled, paths that do not contain the cost community (for the POI and community ID being evaluated) are assigned the default community cost value (2147483647). If the cost community values are equal, then cost community comparison proceeds to the next lowest community ID for this POI.
Applying the cost community attribute at the POI allows you to assign a value to a path originated or learned by a peer in any part of the local autonomous system or confederation. The cost community can be used as a “tie breaker” during the best path selection process. Multiple instances of the cost community can be configured for separate equal cost paths within the same autonomous system or confederation.
Note: in case of aggregate only the highest cost of any individual component route will be applied to the aggregate on a per-ID basis.
Configuration: the feature is enabled if a “set extcommunity cost” command is used on a route map and the route map is applied. The “bgp bestpath cost-community ignore” command can be used to disable the evaluation of the cost community attribute to help isolate problems and troubleshoot issues that relate to BGP best path selection.
Router(config) router bgp 50000
Router(config-router) neighbor 10.0.0.1 remote-as 50000
Router(config-router) neighbor 10.0.0.1 update-source Loopback 0
Router(config-router) neighbor 10.0.0.1 route-map COST1 in
Router(config-router) neighbor 10.0.0.1 send-community both
Router(config) route-map COST1 permit 10
Router(config-route-map) match ip-address 1
Router(config-route-map) set extcommunity cost 1 100
To disable it, once enabled:
Router(config-router)bgp bestpath cost-community ignore
BGP Support for Dual AS Configuration for Network AS Migrations
The “neighbor local-as command” is used to customize the AS_PATH attribute by adding and removing autonomous system numbers for routes received from eBGP neighbors. This feature allows a router to appear to external peers as a member of another autonomous system for the purpose of autonomous system number migration.
router bgp 100
neighbor ip-address remote-as 200
neighbor ip-address local-as 300 [no-prepend [replace-as [dual-as]]
• The “replace-as” keyword is used to prepend only the local autonomous-system number (as configured with the ip-address argument) to the AS_PATH attribute. The autonomous-system number from the BGP routing process is not prepended.
• The “dual-as” keyword is used to configure the eBGP neighbor to establish a peering session using the real autonomous-system number (from the local BGP routing process) or by using the autonomous-system number configured with the ip-address argument (local-as).
BGP Support for Next-Hop Address Tracking
The default BGP Scanner Behavior monitors the next hop of installed routes to verify next-hop reachability and to select, install, and validate the BGP best path. By default, the BGP scanner is used to poll the RIB for this information every 60 seconds. During the 60 second time period between scan cycles, Interior Gateway Protocol (IGP) instability or other network failures can cause black holes and routing loops to temporarily form.
BGP Support for Next-Hop Address Tracking is instead event driven. BGP prefixes are automatically tracked as peering sessions are established. Next-hop changes are rapidly reported to the BGP routing process as they are updated in the RIB. This optimization improves overall BGP convergence by reducing the response time to next-hop changes for routes installed in the RIB. When a bestpath calculation is run in between BGP scanner cycles, only next-hop changes are tracked and processed.
=> Since IOS Release 12.3(14)T BGP next-hop address tracking is enabled by default under IPv4 and VPNv4 address-family sessions. It can be disabled using the “no bgp nexthop trigger enable” command. Further, when enabled, the routing table is walked every 5 seconds to find variation of next-hops which can interest the BGP process (typically tuned for an OSPF or ISIS IGP). This delay can be modified using the “bgp nexthop trigger delay” command in the case of an IGP that converges more slowly (min 1, max 100 seconds).
BGP Fast Peering Session Deactivation
BGP peering deactivation relies by default on Notification messages and in case of non notified teardowns based on the hold down mechanisms. In case of a failure, the BGP table of an hop can stay faulty for up to 180 seconds (default hold time). While this can be limited by setting BGP timers, it is still a timer based approach that does not allow fast convergence in case of sudden, non detectable failure.
BGP fast peering session deactivation improves BGP convergence and response time to adjacency changes with BGP neighbors. This feature is event driven and configured on a per-neighbor basis. When this feature is enabled, BGP will monitor the peering session with the specified neighbor. Adjacency changes are detected and terminated peering sessions are deactivated in between the default or configured BGP scanning interval.
The feature is enabled on a per neighbor basis using the “neighbor ip-address fall-over” command.