Disable flapping BGP neighbors
BGP protocol specifications require a BGP router to use BGP notification messages to
reject invalid routing updates, updates with incorrect attribute combinations or other
protocol errors (including AS number mismatch and duplicate router ID).
The notification messages cause termination of a BGP session and since the
offending data (or configuration error) is usually not removed from the sending
router, the impacted BGP session flaps continuously until a manual intervention,
causing widespread propagation of unnecessary BGP routing updates.
Solution Embedded Event Manager applet or TCL policy can detect flapping BGP
session and shut down the offending BGP neighbor.
The applets described in this article react to at least three BGP-3-NOTIFICATION
syslog messages per minute.
The following EEM applet requires the programming logic and regular expression
support available in Embedded Event Manager 3.0 (first released with Cisco IOS
release 12.4(22)T).
event manager applet BGPNotification
event syslog occurs 3 pattern “BGP-3-NOTIFICATION” period 300
action 100 regexp “neighbors+([0-9]+.[0-9]+.[0-9]+.[0-9]+)” “$_syslog_msg” match id
action 200 if $_regexp_result eq 1
action 300 info type snmp oid bgp.2.0 get-type exact
action 400 cli command “enable”
action 410 cli command “configure terminal”
action 420 cli command “router bgp $_info_snmp_value”
action 430 cli command “neighbor $id shutdown”
action 500 syslog msg “Shut down BGP neighbor $id”
action 510 info type routername
action 520 mail server $_mail_smtp to $_mail_rcpt from “$_info_routername@$_mail_domain” →
subject “ALERT: BGP neighbor $id shutdown due to excessive notifications” body “n$_syslog_msg”
action 999 end
Altenative :
event manager applet BGPNotification
event syslog occurs 3 pattern “BGP-3-NOTIFICATION” period 900
action 100 regexp “neighbors+([0-9]+.[0-9]+.[0-9]+.[0-9]+)” “$_syslog_msg” match id
action 200 if $_regexp_result eq 1
action 300 info type snmp oid bgp.2.0 get-type exact
action 400 cli command “enable“
action 410 cli command “configure terminal“
action 420 cli command “router bgp $_info_snmp_value“
action 430 cli command “neighbor $id shutdown“
action 500 syslog msg “Shut down BGP neighbor $id“
action 510 info type routername
action 600 end
BGP Route Flap Dampening (RFC 2349)
While reading this tutorial, remember that BGP is a routing protocol. That means BGP
learns and selects the best route to a given destination. Anything that makes a route less
preferred causes the router to stop adding the route to the IP routing table and to stop
advertising the route to neighbors.
What is a Route Flap?
BGP peers exchange routes and send updates not faster than every 90 seconds by default.
When a route is repeatedly advertised and withdrawn, it is considered to be ‘flapping‘.
Flapping routes cause instability in the Internet routing table and Cisco routers running
BGP contain an optional mechanism designed to dampen the destabilizing effect of
flapping routes. When a Cisco router running BGP detects a flapping route it automatically
dampens that route. The route dampening prevents routers from thrashing while trying
to re-calculate a large number of route updates. The overall effect is to produce a more
stable routing table. BGP routes can remain in the routing table for months.
The term route flap is used when a previously advertised route is withdrawn and then
readvertised. Cisco IOS later than 11.0 has a route dampening function built into it.
If you are running BGP version 4, the BGP process assigns a penalty of 1000 to the route
each time it flaps. When the penalty value exceeds the first of two limits, the route is
moved into the ‘historical’ list of routes, dampened, and then is no longer accepted from
other peers or announced to any peers. After the first limit has been exceeded, the timer
which tracks the period for which the route is to be dampened is doubled for each flap.
The suppression half-life is 15 minutes. The maximum suppress limit is four times the
half-life; thus, one hour is the default. The suppression penalty decays at half the half life
(7.5 minutes). So:
BGP Route Dampening Terms:
-
Flap—A route whose availability alternates repeatedly
-
History state—After a route flaps once, it is assigned a penalty and put into history
state, meaning the router does not have the best path, based on historical information. -
Penalty—Each time a route flaps, the router configured for route dampening in
another autonomous system assigns the route a penalty of 1000. Penalties are
cumulative. The penalty for the route is stored in the BGP routing table until the
penalty exceeds the suppress limit. At that point, the route state changes from
history to damp. -
Damp state—In this state, the route has flapped so often that the router will not
advertise this route to BGP neighbors -
Suppress limit—A route is suppressed when its penalty exceeds this limit.
The default value is 2000 -
Half-life—Once the route has been assigned a penalty, the penalty is decreased by
half after the half-life period (which is 15 minutes by default). The process of
reducing the penalty happens every 5 seconds. -
Reuse limit—As the penalty for a flapping route decreases and falls below this
reuse limit, the route is unsuppressed. That is, the route is added back to the BGP
table and once again used for forwarding. The default reuse limit is 750. The
process of unsuppressing routes occurs at 10-second increments. Every 10 seconds,
the router finds out which routes are now unsuppressed and advertises them to the world -
Maximum suppress limit—This value is the maximum amount of time a route can
be suppressed. The default value is four times the half-life.
You can check for dampened paths by issuing the following command at the command prompt:
router#show ip bgp dampening dampened-paths
This works on Cisco, Juniper, Avici and HP routers.
Configuring Dampening:
-
enable
- configure terminal
- router bgp autonomous-system-number
- address-family ipv4 [unicast | multicast | vrf vrf-name]
- bgp dampening [half-life reuse suppress max-suppress-time] [route-map map-name]
-
end
Checking default values:
R1#sh ip bgp dampening parameters
dampening 15 750 2000 60 (DEFAULT)
Half-life time : 15 mins Decay Time : 2320 secs
Max suppress penalty: 12000 Max suppress time: 60 mins
Suppress penalty : 2000 Reuse penalty : 750
Transit vs. Non-Transit Peering
When two autonomous systems (AS) peer, they can provide access to all their other peers
or to none of their peers. This is often established as part of the each autonomous system’s
routing policy.
TRANSIT
Transit is when traffic that originates outside your autonomous system, and is destined
for a network outside your AS is permitted to route through your AS. ‘Transit peering‘ is
the term used to describe an arrangement where an eBGP peer is permitted to communicate
with your other eBGP peers. The most common use of this is when an ISP allows their
customers using BGP to access all their other customers using BGP.
For example, let’s say AS 1 wishes to be able to reach AS 5 through AS 4. AS 4 would
accept AS 1’s announcements and then pass the single best route for each destination
on to AS 5. Traffic on AS5, destined for AS 1 may now transit through AS 4. Likewise,
AS1 and AS 4 would need to perform as transit if AS2 wishes to reach AS 5.
2 5
/
1 — 4
/
3 6
NON-TRANSIT
This is when you are providing one eBGP peer access to your network, but not to any
other eBGP peers you might have. This is useful for when a customer is connected to
two ISP’s networks, and wishes to have each ISP’s customers use their own connections
to reach him. The two ISP’s use a non-transit policy, while providing a transit policy for
all their customers. All customers can reach each other, but the ISPs cannot use the other
ISP to reach another ISP.
RIBS AND FIBS (AKA IP ROUTING TABLE AND CEF TABLE)
Every now and then, I’m asked about the difference between Routing Information Base (RIB),
also known as IP Routing Table and Forwarding Information Base (FIB), also known as CEF
table or IP forwarding table.
Let’s start with an overview picture (which does tell you more than the next thousand
words I’ll write):
A router has numerous ways of learning the best paths toward individual IP prefixes:
they might be directly connected, configured as static routes or learned through dynamic
routing protocols.
Each dynamic routing protocol (including RIP) has its own set of internal data structures,
known as OSPF/IS-IS database, EIGRP topology table or BGP table. The routing protocol
updates its data structures based on routing protocol updates exchanged with its neighbors,
eventually collecting all the relevant information.
Throughout this article we’ll work with 10.0.1.1/32 learned through OSPF and 10.0.11.11/32
learned through BGP, so let’s inspect the relevant OSPF/BGP data structures.
!
RR#show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
r>i10.0.1.1/32 10.0.1.1 0 100 0 i
r>i10.0.1.2/32 10.0.1.2 0 100 0 i
*>i10.0.11.11/32 10.0.1.1 0 100 0 i
!
RR#show ip ospf database router 10.0.1.1
OSPF Router with ID (10.0.1.5) (Process ID 1)
Router Link States (Area 0)
LS age: 1612
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 10.0.1.1
Advertising Router: 10.0.1.1
LS Seq Number: 80000003
Checksum: 0xC764
Length: 60
Number of Links: 3
Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.0.1.1
(Link Data) Network Mask: 255.255.255.255
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 10.0.1.6
(Link Data) Router Interface address: 10.0.7.9
Number of MTID metrics: 0
TOS 0 Metrics: 64
Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.0.7.8
(Link Data) Network Mask: 255.255.255.252
Number of MTID metrics: 0
TOS 0 Metrics: 64
reachable through that routing protocol and IP next hops that should be used to reach them.
You can view the results of these route selection algorithms with protocol-specific show
commands (for example, show ip bgp prefix for BGP and show ip ospf rib prefix
for OSPF).
RR#show ip bgp 10.0.11.11
BGP routing table entry for 10.0.11.11/32, version 6
Paths: (1 available, best #1, table default)
Not advertised to any peer
Local
10.0.1.1 (metric 66) from 10.0.1.1 (10.0.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
RR#show ip ospf rib 10.0.1.1
OSPF Router with ID (10.0.1.5) (Process ID 1)
OSPF local RIB
Codes: * – Best, > – Installed in global RIB
*> 10.0.1.1/32, Intra, cost 66, area 0
SPF Instance 2, age 00:48:15
Flags: RIB, HiPrio
via 10.0.2.1, FastEthernet0/0, flags: RIB
LSA: 1/10.0.1.1/10.0.1.1
Both BGP and OSPF associate IP next hops with IP prefixes, but BGP simply uses the
value of the next-hop attribute attached to the BGP route, whereas OSPF computes
the IP address of the next-hop OSPF router with the SPF algorithm.
The results of intra-routing-protocol route selection are inserted in the IP routing table
(RIB) based on administrative distance (and there are interesting consequences if
two routing protocols have the same AD). Most routing protocols don’t complain
when their routes are not used in the IP routing table; BGP has a special show command
that can display RIB failures.
In our scenario, the 10.0.1.1/32 prefix is received via OSPF and BGP and the OSPF
route wins as OSPF has lower AD than internal BGP route.
RR#show ip bgp rib-failure
Network Next Hop RIB-failure RIB-NH Matches
10.0.1.1/32 10.0.1.1 Higher admin distance n/a
10.0.1.2/32 10.0.1.2 Higher admin distance n/a
Ideally, we would use RIB to forward IP packets, but we can’t as some entries in it
(static routes and BGP routes) could have next hops that are not directly connected.
Compare an IBGP route in the IP routing table (RIB) with an OSPF route:
RR#show ip route 10.0.11.11
Routing entry for 10.0.11.11/32
Known via “bgp 65000“, distance 200, metric 0, type internal
Last update from 10.0.1.1 00:00:55 ago
Routing Descriptor Blocks:
* 10.0.1.1, from 10.0.1.1, 00:00:55 ago
Route metric is 0, traffic share count is 1
AS Hops 0
MPLS label: none
RR#show ip route 10.0.1.1
Routing entry for 10.0.1.1/32
Known via “ospf 1“, distance 110, metric 66, type intra area
Last update from 10.0.2.1 on FastEthernet0/0, 00:33:47 ago
Routing Descriptor Blocks:
* 10.0.2.1, from 10.0.1.1, 00:33:47 ago, via FastEthernet0/0
Route metric is 66, traffic share count is 1
OSPF route has an outgoing interface; it’s computed by the SPF algorithm and transferred in the IP routing table. BGP route has no outgoing interface and its next hop is not directly connected; the router has to perform recursive lookups to find the outgoing interface (recursive lookups are also used to implement EBGP load balancing with loopback interfaces).
Early IOS releases performed a recursive lookup on the first packet sent to a new
destination (process switching) and cached the result for subsequent packets
(fast switching). Fast switching worked well in early Internet (with few global IP prefixes),
but as the Internet grew and address-spraying DoS attacks became common, core
routers frequently experienced cachetrashing. Large number of packets were being
process switched, resulting in very high CPU utilization and occasional router meltdown.
It was time to move from cache-assisted forwarding to deterministic forwarding.
Forwarding Information Base (FIB) and Cisco Express Forwarding (CEF) switching
were introduced to make layer-3 switching deterministic. When IP routes are copied
from RIB to FIB, their next hops are resolved, outgoing interfaces are computed and
multiple entries are created when the next-hop resolution results in multiple paths
to the same destination.
For example, when the BGP route from the previous printout is inserted into FIB, its
next-hop is changed to point to the actual next-hop router. The information about the
recursive next-hop is retained, as it allows the router to update the FIB (CEF table)
without rescanning and recomputing the whole RIB if the path toward the BGP next-hop
changes.
RR#show ip cef 10.0.11.11 detail
10.0.11.11/32, epoch 0, flags rib only nolabel, rib defined all labels
recursive via 10.0.1.1
nexthop 10.0.2.1 FastEthernet0/0 label 19
Fully-evaluated FIB (CEF table) can then be used directly for layer-3 switching.
BGP AS-Path Filter Lists
A filter list is a form of route policy that restricts the routes that will be advertised
or accepted based on the AS-Path of the route. To configure a filter list, you must
first create an AS-path access list based on the known paths you wish to permit.
as-path access-list xx permit 701
as-path access-list xx permit 701 6461
as-path access-list xx permit 701 6461 3
!
The list above will permit the following AS-paths:
701
701 6461
701 6461 3
To appy this list to a BGP session, use the following command:
neighbor <IP address> filter-list xx in|out
The list can be applied either to the route received (inbound) or the routes advertised
(outbound). Now let us suppose that to adjust the routing, an administrator at MIT
used AS-path-prepending to make routes to one provider more preferred over another.
This new prepended AS-path would look like this:
701 6461 3 3
This path would never be permitted through the AS-path filter because AS 3 appears
twice. Worse, suppose that after the filter was changed to match this, the administrator
at MIT decided to go back to a standard announcement, or decided to prepend twice.
This would mean a headache for the person maintaining the filter and delay needed
changes.
To make the list more flexible, Cisco has enabled the use of regular expressions in an
as-path filter list. The same list above could be rewritten to permit prepends from all
of the providers in the AS path, and even shorten the list:
as-path access-list xx permit ^(_701)+(_6461)*(_3)$
The filter list above would permit the following AS-paths:
701
701 701
701 6461
701 3
701 6461 3
701 6461 6461 3 3 3
Clearly this second list is shorter, and much more flexible.
The characters that are used above are as follows:
Char. | Meaning |
^ | Beginning of character string |
_ | Any whitespace |
( ) | Brackets are used to group items together |
NNN | The numbers represent the number patterns of the AS numbers. |
* | Zero or more of the previous object |
+ | One or more of the previous object |
The list above will permit the following AS-paths:
701
701 6461
701 6461 3
To appy this list to a BGP session, use the following command:
neighbor <IP address> filter-list xx in|out
The list can be applied either to the route received (inbound) or the routes advertised
(outbound). Now let us suppose that to adjust the routing, an administrator at MIT
used as-path-prepending to make routes to one provider more preferred over another.
This new prepended AS path would look like this:
701 6461 3 3
This path would never be permitted throught the AS-path filter because AS 3 appears
twice. Worse, suppose that after the filter was changed to match this, the administrator
at MIT decided to go back to a standard announcement, or decided to prepend twice.
This would mean a headache for the person maintaining the filter and delay needed
changes.
To make the list more flexible, Cisco has enabled the use of regular expressions in an
as-path filter list. The same list above could be rewritten to permit prepends from all
of the providers in the AS path, and even shorten the list:
as-path access-list xx permit ^(_701)+(_6461)*(_3)$
The filter list above would permit the following AS-paths:
701
701 701
701 6461
701 3
701 6461 3
701 6461 6461 3 3 3
Clearly this second list is shorter, and much more flexible.
The characters that are used above are as follows:
Char. | Meaning |
^ | Beginning of character string |
_ | Any whitespace |
( ) | Brackets are used to group items together |
NNN | The numbers represent the number patterns of the AS numbers. |
* | Zero or more of the previous object |
+ | One or more of the previous object |
BGP weight attribute
Note that in the output of “show ip bgp” above, the weights assigned to each route to
192.168.3.0 are 0:
* 192.168.3.0 192.168.0.13 0 65004 65003 i
*> 192.168.0.2 0 65002 65003 i
we want to route traffic for 192.168.3.0/24 through AS 65004 (R4). The easiest
(but not always best) way to do this is by using BGP’s weight attribute.
Zero is the default value. When multiple routes to the same destination exist, BGP will
prefer the route with the highest weight. To influence traffic to 192.168.3.0 to take the
path through AS 65004 (R4), we need to modify the weight assigned to the route
received from R4. There are a few ways of doing this, but we’re going to use a route
map (probably the most common method).
Just for verification, let’s look at what is currently in our routing table for 192.168.3.0/24:
R1# show ip route | include 192.168.3.0
B 192.168.3.0/24 [20/0] via 192.168.0.2, 00:17:31
We are, indeed, routing traffic to 192.168.3.0/24 via R2 (192.168.0.2).
Defining an access list
We are actually receiving multiple routes from R4, but only want to influence routing
for one route so we are going to use route maps in conjunction with an IP access list to
achieve our desired outcome. First, we need to define an access list that matches
192.168.3.0/24:
R1# configure terminal
R1(config)# access-list 3 permit 192.168.3.0 0.0.0.255
R1(config)# end
!
Defining a route map
With our access list now matching the networks we want to manipulate, we can now
create our route map (which we’ll call “NET3″). Our route map will be configured to
match traffic defined by access list 3 and will set the weight to 100:
R1# configure terminal
R1(config)# route-map NET3 permit 10
R1(config-route-map)# match ip address 3
R1(config-route-map)# set weight 100
R1(config-route-map)# route-map NET3 permit 20
R1(config-route-map)# end
You may be wondering about the “route-map NET3 permit 20″ statement, since it
doesn’t appear to do anything. From Cisco:
That’s exactly what we did in this case. If we had left out the “route-map NET3 permit
20″ statement, any other routes from R4 would not be accepted. Although we are only
going to be manipulating the route to 192.168.3.0/24 from R4, we still need to accept
all other routes from R4 into our BGP table.
Applying a route map to a neighbor
With our route map configured, we now need to instruct R1 to apply the route-map to
any updates received from our neighbor, R4. Easy enough:
R1# configure terminal
R1(config)# router bgp 65001
R1(config-router)# neighbor 192.168.0.13 route-map NET3 in
R1(config-router)# end
We’re pretty much set at this point. The changes won’t take effect immediately,
however. We need to restart the BGP process in order for our changes to take effect.
Let’s restart:
R1# clear ip bgp 65004
If we take a look at our BGP table, we should see that the route for 192.168.3.0/24 that
came from R4 (AS 65004) should now have a weight of 100 assigned to it, and it does:
*> 192.168.3.0 192.168.0.13 100 65004 65003 i
- 192.168.0.2 0 65002 65003 i
Subsequently, we should see that the “new” route to 192.168.3.0/24 (via 192.168.0.13
in AS 65004) was installed into our routing table:
R1# show ip route | include 192.168.3.0
B 192.168.3.0/24 [20/0] via 192.168.0.13, 00:01:56
And that’s all there it is to it!
The Basics of BGP Route Reflection
A BGP speaker will not advertise a route learned via another IBGP speaker to a third
IBGP speaker. By relaxing this restriction a bit and by providing additional control,
we can allow a router to advertise (reflect) IBGP learned routes to other IBGP
speakers. This will reduce the number of IBGP peers within an AS.
The rule states: that any route received from an iBGP neighbor must not be advertised
to any other iBGP neighbor.
Configuring Border Gateway Protocol (BGP) can be quite onerous, particularly with
large numbers of peering sessions that must be configured manually. In fact, in a
large network, the full-mesh requirement for IBGP can be a provisioning nightmare.
BGP’s answer to the IBGP pairing configuration nightmare that is the full mesh is
called route reflection. Route reflection allows sharing of routing information among
a group of routers without having to send the exact same information to each of them
individually. It’s sort of like giving information to one person and having them
distribute it to all their peers.
IBGP comes with a significant restriction: IBGP peers should not re-advertise IBGP–
learned routes to other IBGP speakers, which is why they all need to be fully meshed.
If you can’t re-advertise IBGP routes, you must be directly connected to the originator
of the route, hence the full mesh requirement. Remember, IBGP has no dedicated loop
prevention mechanism, and this is why you need route reflectors for large networks.
The concept of route reflection allows you to designate one or more of your routers as
route reflectors. BGP relaxes the re-advertising restriction on these route reflectors,
allowing them to accept and propagate IBGP routes to their clients.
As the IBGP learned routes are reflected, it is possible to have the routing information
loop. The Route Reflector scheme has a few methods to avoid this:
Originator−id: this is an optional, non transitive BGP attribute that is four bytes long
and is created by a RR. This attribute will carry the router−id (RID) of the originator of
the route in the local AS. Thus, due to poor configuration, if the routing information
comes back to the originator, it will be ignored.
neighbor 6.6.6.6 route−reflector−client
A route reflector is BGP router that is allowed to break the iBGP loop avoidance rule.
Route reflectors can advertise updates received from an iBGP peer to another iBGP
peer under specific conditions.
By breaking the rules, route reflectors are used to eliminate the full mesh requirement
and allow for building iBGP networks that scale easily and cleanly.
How is this accomplished?
BGP Route Reflector follows the below listed rules to achieve this goal:
iBGP routers are divided into Route Reflectors, Route Reflector clients and non-client
Peers. Routes received from a Route-Reflector-client is reflected to other clients and
non-client neighbors. Routes received from non-client neighbors are reflected to
Route-Reflector-client neighbors only.
Setting the Originator-ID attribute in the reflected update if it is not already set.
Adding the Cluster-ID to the Cluster-list attribute in the reflected update.
A Route Reflector reflects routes considered as best routes only. If more than one
update is received for the same destination, only the BGP best route is reflected.
A Route Reflector is not allowed to change any attributes of the reflected routes
including the next-hop attribute.
Route Reflectors and Loop Prevention :
The following rules are used to detect and avoid routing loops caused by route
reflection:
If a router received an iBGP route with the Originator-ID attribute set to its own
router-id, the route is discarded. If a route reflector receives a route with a cluster-list
attribute containing its cluster-id, the route is discarded.
What is BGP, where/when are we gonna use it ?
Overview:
A) BGP is the successor of EGP [Exterior Gateway Protocol], and currently its the only
EGP deployed. BGP is an Enhanced Distance Vector Protocol used in routing between
Autonomous Systems [AS] “aka Interdomain Routing”, where an AS is a collection of
networks under single administration.
We use BGP in several occasions as Service Providers networks, Multihomed
customers and large enterprise networks, etc…
BGP Basics:
- Only one BGP process per router.
- There is two types of BGP, IBGP & EBGP, if the as-numbers of the peering routers
are the same then its IBGP, if they are different then its EBGP. - BGP uses AS numbers [1-64511] as public and [64512-65535] as private.
- BGP uses TCP as its reliable transport protocol and it runs over TCP port 179.
- The router with the higher router-id establishes the BGP peering session.
- BGP uses Keepalive messages to detect the presence of its neighbor, Keepalive
interval value is 60 sec, and Holdtime is 180 sec by default [1:3 ratio],
Holdtime value is exchanged in the Open Message, and you can only modify
the Holdtime value, BGP peers use the lower Holdtime value configured on
either of them. - BGPuses triggered updates, 5 sec interval for IBGP and 30 sec interval for
EBGP. - Mandatory well known attributes must exist in each routing update.
- If multiple paths exist for the same network, only one is selected as the best
route and the remaining routes are stored in the memory, Router propagates
best routes only to its neighbors. - If multi path load sharing is enabled, router can select multiple paths to a
single destination and installs them in the routing table, multiple path load
sharing in BGP supports up to 16 paths. - Before a route is installed in the routing table, the router checks if its learned
from another routing protocol rather than BGP, if it was learned from another
routing protocol the router compares the Administrative Distance [AD] and
prefers the lower. - BGP Split Horizon Rule: When a router receives an update it never sends it
back to the source which it received from. - IBGP Split Horizon Rule: Routes learned from an IBGP neighbor is never sent
to other IBGP neighbors, thus all IBGP routers inside an AS needs full mesh for
consistent routing decisions. - AS-Path loop prevention mechanism: When a router receives an update
containing its own AS number; it silently ignores the update. - EBGP peers should be reachable for all BGP speaking routers inside an AS,
this is achieved by either redistributing connected interfaces of the EBGP peers
into IGP, or run IGP over the EBGP peers interface and make them passive so
that they don’t exchange IGP information, or finally use the “neighbor ip-
address next-hop-self” command so that the edge router announces it self as
the next hop for the IBGP peers. - BGP sessions can be initiated using loopback interfaces, IGP or Static Routes
are used for providing reachability between loopbacks, also the update source
for the BGP session should be modified in order to successfully establish the
session using the “neighbor ip-address update-source loopback number”
command. For EBGP sessions to be established successfully using the
loopback interfaces you will need to use the “neighbor ip-address ebgp-
multihop value“ command. - IGP is used inside an AS to provide full reachability required for establishing
IBGP sessions, fast convergence in case of physical failure in one of the
multiple paths between IBGP routers, and next hop resolving “aka recursive
look up” for appropriate packet forwarding.
BGP Path Attributes :
- Mandatory Well Known Attributes:
- Next-hop:ip address of the router sending the updates, by default it
changes when a route is advertised to EBGP neighbor but not when its
advertised to IBGP neighbor. - AS-Path:Sequence of ASs path a route has traveled through.
- Origin: Indicates how BGP learned the route [IGP – EBGP – ?].
- Next-hop:ip address of the router sending the updates, by default it
- Discretionary Well Known Attributes:
- Local Preference:used for consistent routing policy inside an AS.
- Atomic Aggregate: informs a neighbor router that the originating router
aggregated the routes.
- Transitive Optional Attributes:
- Aggregator:Specify the ip address and the AS number of the router that
performed the aggregation. - Community: Route tagging mechanism used in filtering or route
selection process.
- Aggregator:Specify the ip address and the AS number of the router that
- Non-Transitive Optional Attributes:
- Multi-Exit Discriminator [MED]: Discriminate between multiple exit points within an AS.
- Cost Community: Used to influence best-path selection for IBGP and
confederations only. - Originator-id: Used as a loop prevention mechanism in case of multiple
Route Reflectors.
BGP Session Establishment Process :
- Single BGP process is started on the router using “router bgp as-number”
command. - Neighbors must be configured manually on both sides using “neighbor ip-
address remote-as as-number“ command. - It uses TCP port 179 and the session of the router with the higher Router-id is
retained. - The first state of the BGP session is IDLE which indicates that the router is
currently not attempting any session establishment, for a router to change its
IDLE state; the configured neighbor ip address should be reachable. - When peers are correctly configured the state is changes to ACTIVE which
indicates that the router is actively sending connections attempts to its
neighbor. - When the TCP connection attempt succeed, the router sends an Open Message
containing BGP session information and changes the state to be OpenSent.
The Open Message contains [BGP version number – AS of local router –
Holdtime – Router-ID – Optional parameters]. - If the neighbor router accepts the parameters in the Open Message; it replies
with its own Open Message, the local router receives the Open Message and
changes the state to OpenConfirm, and it verifies the parameters of the
neighbor router, if accepted a keepalive message is sent as signal of acceptance
and then the state is changed to Established.
Route Selection Criteria :
- Next-hop: If not reachable the route is not installed in the routing table.
- Weight: Local to the router.
- Local Preference: Local within an AS.
- Originated Routes: Routes originated using the network or summary
commands. - AS-Path: Prefers the shortest path.
- Origin Code: IGP < EGP < ?
- MED: Prefers the lowest value.
- EBGP routes over IBGP routes.
- For IBGP: Prefers path via closest IGP neighbor [Next-Hop with lowest IGP
metric]. - For EBGP: Oldest path.
- Lowest BGP Router-id.
Advertising Networks :
There are three ways to announce networks into BGP :
- Network command, Redistribution and Aggregation.
- when either of the three ways is used the AS-Path will appear empty indicating
that the route is locally originated, when the route traverses through other
ASes, the forwarding router prepends its own AS number to the AS-Path. - Network command operates differently in BGP; indicates which routes will be
injected in the BGP table not which interface will BGP run over. - Using a Route-Map with the Network command allows you to alter Weight,
Local Preference, MED and tagging the route. - When redistributing routes into BGP, they carry an origin of incomplete “?“. –
Conditional Route Injection: is injecting a route into BGP with no matching
route in the routing table, this is achieved by using the “bgp inject-map map-
name exist-map map-name” command.
Summarization & Aggregation :
- Automatic summarization is enabled by default.
- For a router to install a classful network in the BGP table when Automatic
summarization is enabled; A classful network statement with a classful mask
and at least one subnet of this classful network should exist in the routing
table. - When Automatic summarization is enabled; all redistributed subnets will be
summarized to their classful network. - When summarization is disabled, an exact match must be found in the routing
table. - Aggregation is summarization of routes when it is advertised to other
neighbors, and its configured using “aggregate-address ip-address
mask”command. - For an aggregate route to be advertised to other neighbors; a route within the
range of the aggregate must exist in the BGP table in order to install the
aggregate in the BGP table. - By default both the aggregate and the specific routes are advertised to the
neighbors, to advertise the aggregate only you will have to use the “summary-
only” keyword with the aggregate command.
Securing BGP Peers :
- MD5 authentication between BGP peers by using the “neighbor ip-address
password password” command. - TTL-Security: The router compares the TTL value received with the locally
configured hop count value, this option is supported for both directly connected
and multihop EBGP peers. the command for this option is “neighbor ip-
address ebgp-multihop ttl“; where TTL is a numeric value.
Multihoming :
- Multihoming is a customer being connected to a single ISP with multiple links
or connected to multiple ISP’s. - Multihomed customers should run BGP with their ISPs using public AS and
provider independent address space. - Multihomed customers should advertise their own address space only to their
ISPs and do not advertise routes learned from their ISPs do avoid acting as a
Transit-AS between their ISPs. - For influencing Upstream ISP selection, Weight and Local Preference can be
used inside a Multihomed Customer AS. - For influencing Downstream ISP selection, MED can be used if the customer is
multihomed to a single ISP as MED doesn’t traverse through ASes, and AS-
path Prepending can be used if the customer is multihomed to multiple ISPs
because AS-path attribute traverses through ASes.
AS-Path Filtering :
- Used to announce or accept prefixes based on AS-Path Attribute.
- It uses Regular Expressions.
- Its implemented on per neighbor basis.
- Use “ip as-path access-list number [permit/deny] as-regular-expression” &
“neighbor ip-address filter-list access-list-number [in/out]” commands.
Prefix-List filtering :
- Used to filter announce and accept specific prefixes.
- It has some advantages over IP Access Lists as: Provide flexibility in editing,
inserting and deleting individual lines, Matches based on subnetmask, etc… - Its implemented on per neighbor basis.
- An with no Le/Ge matches exactly the specified prefix.
- An entry with Le/Ge matches any route within the range specified.
- Configuration example :
- “ip prefix-list name seq number [permit/deny] prefix/length ge value le value” “neighbor ip-address prefix-list name [in/out]” “redistribute-list prefix-list name out routing-process“.
Out Bound Route Filtering [ORF] :
- Its implemented on per neighbor basis.
- Its a BGP feature that allows a router to accept a prefix-list from a neighbor and
apply it to locally configured ORF neighbor. - A router can install an inbound prefix-list to a peer as an outbound prefix-list.
- Its used to minimize the number of updates sent between neighbors and reduce
system resources. - Configuration example :
- “neighbor prefix-list name [in/out]” “neighbor capability orf prefix-list
[send/receive/both]”
- “neighbor prefix-list name [in/out]” “neighbor capability orf prefix-list
ORF message contains :
- Address Family Information [AFI]/ Subsequent AFI
- ORF types
- When to refresh
- List of ORF entries
ORF Types :
- type 1 –> Network Layer Reachability Information [NLRI]
- type 2 –> Communities
- type 3 –> Extended Communities
- type 128 –> Prefix-List
Route-Map Filtering :
- Route-Map matches: prefix-list/access-list/route originator/next-
hop/origin/AS-path/community/IGP tag/IGP type[internal/external]. - Route-Map can set: origin/next-hop/weight/local preference/MED/community.
- IP Policy List: is grouping of route-map match clauses then attaching to route-
map. - Its implemented on per neighbor basis.
- Route Map Continue Cause: its like the match and the set causes of the route-
map, when a match in the route-map is successful continue clause -if
configured- jumps to a pre-specified route-map entry, the continue clause takes
place if a match is successful, if not then it is ignored. - If the route-map has no match clause, the continue clause takes place
automatically, if a match is successful the continue clause takes place, if not
then it is ignored. - Configuration example:
- “ip policy-list name [permit/deny]match [as-path/metric/community]
route-map name permit seq-number match policy-map namematch ip address prefix-list namematch ip next-hop prefix-list namematch ip route-source prefix-list name continue seq-number
neighbor ip-address route-map name[in/out]”
- “ip policy-list name [permit/deny]match [as-path/metric/community]
AS-Path Prepending :
- Used to influence other ASes to select a specific return path towards an AS.
- Used to distribute the load of returning traffic for multihomed customers,
however in this case you will have to monitor the traffic and prepend AS to path
as needed to accomplish the traffic load. - To avoid BGP AS-Path loop prevention mechanism, use only the AS number of
the sending AS. - Service Providers use AS-Path filter to allow routes that are originated from
Customers AS only, if the Customer is going to use AS-Path prepending the
Service Provider will have to change their filter to allow AS-Path containing
more than one copy of Customer’s AS number. - AS-Path prepending is applied using Route-Maps on per neighbor basis.
”route-map route-map-name permit 10 set as-path prepend as-no as-no as-no
neighbor ip-address route-map route-map-name out”.
BGP hide local AS :
- The “neighbor ip-address local-as as-number [no-prepend [replace-as [dual-
as]]]”- no-prepend: does not prepend local AS number to any learned EBGP
routes. - replace-as: replaces the local AS number with the one set int the
command to the AS-path attribute. - dual-as: allows the establishment of EBGP sessions using either the
real AS number or using the AS number set in the command.
- no-prepend: does not prepend local AS number to any learned EBGP
- This usually happens while connecting two different BGP networks with
different AS numbers to not disturb the established peerings [i.e. when an ISP
buys another ISP and merging both networks into only one network]. - Its drawback : if you configured the above command with an AS number that
already exists for one of the IBGP peers, when this IBGP receives the route it
will detect its own AS number in the AS path and it will ignore this route
considering it as a routing loop.
Multi-Exit Discriminator [MED] :
- MED is used to discriminate between multiple exit points within an AS.
- MED is used to influence path selection in neighbor AS.
- MED doesn’t traverse outside the receiving AS.
- Default value is Zero and in comparison the lower value the better, to change
the default value use “default-metric number” command. - MED can be set in ways:
- Using a Route-Map
- Inherited from an IGP by either using the BGP Network command or
redistributing into BGP.
- MED is compared when different values are received from same AS, if “bgp
always-compare-med” is used MED from different ASes will be also compared. - In intra-confederations MED is not compared and to compare it “bgp bestpath
med confed” should be used. - BGP sets a missing MED value to infinite value, however Cisco IOS does set it
to Zero, to change this behavior of Cisco IOS the “bgp bestpath med missing-
med-worst” command should be used. - “bgp deterministic-med” allows BGP to compare the MED values after the AS-
Path attribute directly.
- Its a mean of tagging routes and used in filtering or route selection.
- By default its stripped in outgoing BGP updates, to enable sending
communities the “neighbor ip-address send-community” should be used in
per-neighbor basis. - There is no limitation on the number of communities specified for a route.
- Route-Map is used for setting the community value, it can be applied with
redistribution, network command, neighbor command and aggregate
command. - In Route-Map configuration, the “additive” keyword prepends new Community
value to the existing Community values, if not used it will override the existing
Community values. “set community value [value …][additive]” - The “ip bgp-community new-format” command is recommended when the
Community value contains AS numbers. - Community list “ip community-list 1-99 permit|deny value [value …]”:
- Values in one line must match to be accepted, if no matches the list acts as an
Access-List and denies the route. - Keyword “internet” acts as permit any.
- Extended Community list “ip community-list 100-199 permit|deny regexp”
- Matches are based on regular expressions.
- To match any use “.*” value.
- Named Community list “ip community-list standard|expanded name permit|deny value|regexp”.
- Sequenced Extended Community List “ip extcommunity-list 100-199|standard list-name permit|deny regexp” or “ip extcommunity-list 0-99|expanded list-name permit|deny [rt extcom-value][soo extcom-value]”
- Allow automatic sequencing or re-sequencing for BGP Extended Community
List - Allow insertion and deletion of lines in the BGP Extended Community List.
- Rt: Specifies the Route Target of Extended Community attribute.
- Soo: Specifies the Site Of Origin Extended Community attribute.
- BGP Cost community “set extcommunity cost [igp] community-id cost-value”
- Its a non-transitive attribute.
- Its used to influence best-path selection for IBGP and confederations
only. - Default value is 2147483647 and in comparison the lower value the
better. - The keyword “IGP”influences the best-path selection at the POI [point of
insertion] which follows the IGP metric comparison in BGP route
selection criteria. In case if the POI step is not valid the cost community
is silently ignored.
BGP Link Bandwidth :
- Used for load balancing over unequal bandwidth links.
- Enabled by using “bgp dmzlink-bw”.
- Routes learned from a directly connected external neighbor propagates through
the IBGP network with the bandwidth of the external link. - The “neighbor ip-address dmzlink-bw” command is used to advertise the
bandwidth of links used to exit an AS, its configured on the DMZ interface that
connect single hop EBGP neighbor.
Route Reflectors :
- Route Reflectors are router running BGP that are allowed to break the IBGP
loop prevention rules and advertise routes that are received from IBGP pears. - Route Reflectors eliminates the need of full mesh IBGP.
- Route Reflector advertises the best routes only.
- When Route Reflector receives a route update from a Route Reflector Client; it
sends the route to all other peers. - When Route Reflector receives a route update from a Non Route Reflector
Client; it sends the route to all of its Clients and EBGP peers only. - When a Route Reflector Client receives an IBGP route update; it sends it to
EBGP neighbors only. - When a Route Reflector Client receives an EBGP route update; it sends it to all
of its neighbors. - In case of redundant Route Reflectors; Route Reflector Clusters is used to
prevent routing loops, the Route Reflector adds Cluster-id and Originator-id to
the advertised route updates. - Originator-id is a non-transitive optional attribute.
- When a Route Reflector receives a route update with its own Cluster-id; it
silently ignores the route update. - When a Route Reflector Client receives a route update with Originator-id same
as its Router-id; it silently ignores the route update. - When a Route Reflector receives two IBGP route updates; the non reflected
route update [the one with no Originator-id] is preferred. - When a Route Reflector receives two IBGP route updates ; the one with the
shortest Cluster-list is preferred.
- Route Reflector configuration:
- “neighbor ip-address route-reflector-client”
- “bgp cluster-id cluster-id”
- Confederations splits the AS into smaller ASes to reduce the number of BGP
sessions needed for full mesh IBGP. - Confederations eliminates the need of full mesh IBGP, however its needed
inside each Confederation which can be achieved by setting a Route Reflector
inside the Confederation. - When communicating to real EBGP neighbors, internal ASes are hidden and
only one external AS is announced to all real EBGP neighbors. - Intra-Confederation EBGP sessions are used between Member-ASes, however
it is slightly different from the Real EBGP sessions as is behaves like IBGP in
passing BGP attributes as Local-Preference, MED, Next-Hop. - Entire Confederation should use same IGP as they all use same Next-Hop ip-
addresses. - Intra-Confederation AS-Path appears between parentheses ( ).
- To configure Confederations:
- Start the BGP process with the Member-AS number.
- Set the external “Real” AS number.
- List all Member-ASes of the Confederation on each router with EBGP
Session. - “router bgp member-as” “bgp confederation identifier external-as” “bgp
confederation peers list-of-member-as”
Peer Groups :
- Used to configure multiple neighbors with similar requirements, also used as a
BGP performance enhancement tool since the router builds a single update for
all Peer Group members which reduces the CPU load. - IBGP & EBGP neighbors cannot be mixed in one Peer Group.
- Peer Group parameters can be overridden by per-neighbor configurations on
incoming updates only. - Peer Group configuration: “neighbor group-name peer-group” “neighbor
group-name bgp-parameters” “neighbor ip-address peer-group group-name”
Route Dampening :
- Used to reduce processing load caused by flapping routes.
- IBGP routes are not dampened.
- When an EBGP route flaps it gets 1000 Penalty Points, when the Penalty
Points exceeds the Suppress Limit the route is dampened. The Penalty Points
decay through the use of a decay algorithm, when it drops below the reuse limit
the route is re-advertised. - Flapping history of a route forgotten after the Penalty drops below than half of
the Reuse Limit. - After enabling Route Dampening; routes in the BGP Table are never removed,
the route is kept in the BGP Table and marked as history “h”. - To enable Route Dampening, the “bgp dampening [half-life reuse suppress
max-suppress-time] [route-map route-map-name] command is used.- half-time → time for penalty to decrease to half [default value is 15
minutes]. - suppress → limit in which penalty of a route exceeds the route is
suppressed [default value is 2000]. - reuse → limit in which penalty of route drops below, the route is
unsuppressed [default value is 750]. - max-suppress-time → no route is suppressed longer than this duration
[default value is 60 minutes & maximum us 255 minutes].
- half-time → time for penalty to decrease to half [default value is 15
- Useful commands :
- To clear the statistics of routes flaps “clear ip bgp flap-statistics”.
- To release Dampened Routes “clear ip bgp dampening”.
- “show ip bgp dampened-paths”.
“show ip bgp flap-statistics [ regexp regexp | filter-list access-list | ip-address mask [longer-prefix] ]”.