Networking-Blog

Tags: bgp, route reflector

by admin

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 – ?].
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.

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]”

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]”

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.

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].
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] ]”.

September 21, 2012 2:13 pm

Tags: bgp

by admin

What is the BGP Best Path Selection Algorithm?

With the full Internet BGP routing table being upward of 200K routes and with a BGP
router having the potential to be receiving multiple copies of that routing table from
multiple providers, it has to have some way to compare those multiple BGP routing tables
and select only the best route to go into the IP routing table on the router. It uses the
BGP Best Path Selection Algorithm to do this.

You should note that Cisco BGP routers have weight as the first criteria in the table
where other brands of routers do not.

Unless there are no options in place to influence the result, the BGP Best Path selects
the best path b are put in place by network administrators.

Let’s look at the selection criteria, in order, that BGP uses to select the best routes to
install into the IP Routing table:

1 Weight — This is a Cisco-defined attribute that is assigned locally to your router
and does not get carried through to the router updates. If there are multiple paths to a
particular IP address (which is very common), then BGP looks for the path with the
highest weight. There are several ways to set the weight parameter, such as the neighbor
command, the as-path access list, or route maps.

2 Local Preference — This is an indicator to the AS as to which path has local
preference, with the highest preference being preferred. The default is 100. For example:

bgp default local-preference 150

3 Network or Aggregate — This criterion prefers the path that was locally
originated via a network or aggregate. The aggregation of specific routes into one
route is very efficient and saves space on your network.

4 Shortest AS_PATH — BGP uses this one only when there is a “tie” comparing
weight, local preference, and locally originated vs. aggregate addresses.

5 Lowest origin type — This deals with protocols such as Interior Gateway
Protocol (IGP) being a lower preference than Exterior Gateway Protocol (EGP).

6 Lowest multi-exit discriminator (MED) — This is also known as the external
metric of a route. A lower MED value is preferred over a higher value.

7 eBGP over iBGP — Similar to #5, BGP AS Path prefers eBGP over iBGP.

8 Lowest IGP metric — This criterion prefers the path with the lowest IGP metric
to the BGP next hop.

9 Multiple paths — This determines if multiple paths require installation in the routing
table.

10 External paths — When both paths are external, it prefers the path that was
received first (the oldest one).

11 Lowest router ID — This prefers the route that comes from the BGP router with
the lowest router ID.

12 Minimum cluster list — If the originator or router ID is the same for multiple
paths, it prefers the path with the minimum cluster list length.

13 Lowest neighbor address — This prefers the path that comes from the lowest
neighbor address.

September 21, 2012 2:01 pm

Tags: bgp, path selection

by admin

Influencing BGP path selection with the extcommunity cost attribute

Many of you out there should be familiarized with the BGP path selection process,
but I bet some of you (as me, until I recently found out) didn’t knew that by using the
extcommunity cost attribute, we might be able to somehow modify the BGP path
selection algorithm.

So what is the extended community cost attribute?.

The BGP Cost Community feature introduces 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.

This next diagram will be the topology I’ll be working on to demonstrate how this
could be done:

Network Topology BGP

First, we build a basic BGP configuration on every router according to the diagram
above. After that is done, if we take a look on R1 BGP table it should look like this:

R1#sh ip bgp
BGP table version is 2, local router ID is 192.168.123.1
Status codes: s suppressed, d damped, h history, * valid, > best, 
i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
* i10.10.10.0/24    192.168.123.3            0    100      0 400 i
*>i                 192.168.123.2            0    100      0 400 i

R1#sh ip bgp 10.10.10.0
BGP routing table entry for 10.10.10.0/24, version 4
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Flag: 0xA60
  Not advertised to any peer
  400
    192.168.123.3 from 192.168.123.3 (192.168.123.3)
      Origin IGP, metric 0, localpref 100, valid, internal
  400
    192.168.123.2 from 192.168.123.2 (192.168.123.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best

We can see that both paths for prefix 10.10.10.0/24 (a loopback interface on R4)
have the same attributes. If we follow the steps in the BGP path selection algorithm,
we can deduce that the next hop 192.168.123.2 is being chosen as the best path
because it’s the path announced by the router with the lowest router-id, in this
case R2.

Imagine you are in the lab, and they give you a task stating something like

“Make R1 to prefer the route to 10.10.10.0/24 through R3 but, without modifying
local preference, weight, as-path, bgp router-id or IGP metric to next-hop”
(evil I know ). This is one case when the extcommunity cost could result useful.

Let’s do the configuration, we need to make R1 and R3 send community values:

R1(config)#router bgp 123 
R1(config-router)#neighbor 192.168.123.3 send-community both
!
R3(config)#router bgp 123 
R3(config-router)#neighbor 192.168.123.1 send-community both

Then on R3, we build a route-map, where the extcommunity cost setting will take place:

R3(config)#ip prefix-list TRICKY-TASK permit 10.10.10.0/24 
R3(config)#route-map TASK permit 10 
R3(config-route-map)#match ip add prefix-list TRICKY-TASK 
R3(config-route-map)#set extcommunity cost 1 100 
R3(config-route-map)#exit 
!
R3(config)#route-map TASK permit 20 
R3(config-route-map)#exit

And then we apply the route-map in R3 for the R1 neighbor relationship,
and clear the BGP process for that neighbor:

R3(config)#router bgp 123 
R3(config-router)#neighbor 192.168.123.1 route-map TASK out 
R3(config-router)#do clear ip bgp * soft out

That’s it, now we need to verify. To do that, we take a look at R1’s BGP table so we
can see the effect of the route-map in the route:

R1#sh ip bgp 10.10.10.0

BGP routing table entry for 10.10.10.0/24, version 5 
Paths: (2 available, best #1, table Default-IP-Routing-Table) 
Flag: 0xA60 Not advertised to any peer 400
    192.168.123.3 from 192.168.123.3 (192.168.123.3) 
Origin IGP, metric 0, localpref 100, valid, internal, 
best Extended Community: Cost:igp:1:100
  400 192.168.123.2 from 192.168.123.2 (192.168.123.2) 
Origin IGP, metric 0, localpref 100, valid, internal

September 20, 2012 1:00 pm

Tags: bgp, community, excommunity

by admin

BGP ROUTE-MAP SET MED

In the following example,

route map freddy marks all paths originating from autonomous system 690 with a Multi Exit Discriminator
(MED) metric attribute of 127. The second permit clause is required so that routes not matching autonomous system path list 1 will still be sent to neighbor 1.1.1.1.

router bgp 100
neighbor 1.1.1.1 route-map freddy out
!
!
route-map freddy permit 10
match as-path 1
set metric 127
!
route-map freddy permit 20
match as-path 2
!
!
ip as-path access-list 1 permit ^690_
ip as-path access-list 2 permit .*

February 20, 2012 9:40 pm

Tags: bgp med

by admin

BGP Path Filtering by Neighbor

The following is an example of BGP path filtering by neighbor. The routes that pass as-path access list 1
will get weight 100. Only the routes that pass as-path access list 2 will be sent to 193.1.12.10.
Similarly, only routes passing access list 3 will be accepted from 193.1.12.10.

router bgp 200
neighbor 193.1.12.10 remote-as 100
neighbor 193.1.12.10 filter-list 1 weight 100
neighbor 193.1.12.10 filter-list 2 out
neighbor 193.1.12.10 filter-list 3 in
!
!
ip as-path access-list 1 permit _109_
ip as-path access-list 2 permit _200$
ip as-path access-list 2 permit ^100$
ip as-path access-list 3 deny _690$
ip as-path access-list 3 permit .*

February 20, 2012 9:15 pm

Tags: bgp filtering

by admin

BGP SET AS-PATH

In the following example, the route map called set-as-path is applied to outbound updates to the
neighbor 200.69.232.70.

The route map will prepend the autonomous system path “100 100” to routes that pass access list 1.
The second part of the route map is to permit the advertisement of other routes.

router bgp 100
network 171.60.0.0
network 172.60.0.0
neighbor 200.69.232.70 remote-as 200
neighbor 200.69.232.70 route-map set-as-path out
!
route-map set-as-path 10 permit
match address 1
set as-path prepend 100 100
!
route-map set-as-path 20 permit
match address 2
!
access-list 1 permit 171.60.0.0 0.0.255.255
access-list 1 permit 172.60.0.0 0.0.255.255
!
access-list 2 permit 0.0.0.0 255.255.255.255

February 19, 2012 11:23 pm

Tags: bgp as-path

by admin

BGP – Configuring Route Reflectors

Router reflection is an alternative to confederations as a strategy to reduce IBGP meshing.
BGP specifies that a BGP speaker cannot advertise routes to an IBGP neighbor if the speaker learned the
route from a different IBGP neighbor.

A route reflector is a BGP speaker that advertises routes learned from each of its IBGP neighbors to its
other IBGP neighbors; routes are reflected among IBGP routers that are not meshed. The route reflector’s neighbors are called route reflector clients.
The clients are neighbors only to the route reflector, not to each other. Each route reflector client
depends on the route reflector to advertise its routes within the AS; each client also depends on the
route reflector to pass routes to the client.

A route reflector and its clients are collectively referred to as a cluster. Clients peer only with a
route reflector and do not peer outside their cluster. Route reflectors peer with clients and other
route reflectors within the cluster; outside the cluster they peer with other reflectors and other routers
that are neither clients nor reflectors. Route reflectors and nonclient routers must be fully meshed.

Clients and nonclients have no knowledge of route reflection; they operate as standard
BGP peers and require no configuration.

Route reflectors advertise routes learned from:

A nonclient peer only to clients
A client peer to all nonclient peers and to all client peers except for the originator of the route
An EBGP peer to all nonclient peers and all client peersIllustrates a simple route reflection setup.Configured as a route reflector, Router Harvard reflects routes among its
clients within Cluster 23: Routers Plymouth, Westford, and Acton.
These route reflector clients see router Harvard and each other simply as IBGP neighbors.
Router Newport in AS 325 and router Mason in AS 413 see router Harvard simply as
an EBGP neighbor in AS 29.
To configure router Concord as a route reflector:
router bgp 29
neighbor 10.7.1.3 remote-as 29
neighbor 10.7.1.3 route-reflector-client
neighbor 10.7.1.4 remote-as 29
neighbor 10.7.1.4 route-reflector-client
neighbor 10.7.6.2 remote-as 29
You do not configure a cluster ID, because router Concord is the only route reflector in this cluster.
To configure router Acton :
!
router bgp 29
bgp cluster-id 23
neighbor 10.3.1.1 remote-as 29
neighbor 10.3.1.1 route-reflector-client
neighbor 10.1.2.3 remote-as 29
neighbor 10.1.2.3 route-reflector-client
neighbor 10.3.3.4 remote-as 29
neighbor 10.2.5.1 remote-as 29
You must configure a cluster ID, because router Acton and router Harvard are both route reflectors
in this cluster.
To configure router Harvard as a route reflector:
!
router bgp 29
bgp cluster-id 23
neighbor 10.3.1.2 remote-as 29
neighbor 10.3.1.2 route-reflector-client
neighbor 10.1.2.1 remote-as 29
neighbor 10.1.2.1 route-reflector-client
neighbor 10.3.3.2 remote-as 29
neighbor 10.2.5.2 remote-as 29
!
You must configure a cluster ID, because router Harvard and router Acton are both route reflectors
in this cluster.
bgp client-to-client reflection
- Use to reenable the reflector to reflect routes among all clients.
- Client-to-client reflection is enabled by default. If the route reflector’s clients are
  fully meshed, you can disable reflection because it is not necessary.
- If client-to-client reflection is enabled (the default), clients of a route reflector
  cannot be members of a peer group.
- Example
```
no bgp client-to-client reflection 
```
- Changes apply automatically to any routes received after you issue the command.
  To advertise or withdraw routes that are already present in the BGP RIB, you
  must use the clear ip bgp command to issue a hard clear or an outbound
  soft clear.
- Use the no version to disable route reflection; use only if the route reflector’s clients are fully meshed.
bgp cluster-id
- Use to configure a cluster ID on the route reflectors if the BGP cluster has more than one
  route reflector. For clusters with a single reflector, the cluster ID
  is the reflector’s
  router ID and does not have to be configured.
- You specify a cluster ID number or an IP address of a router acting as a route reflector.
- The new cluster ID is used in update messages sent after you issue the command.
  To force BGP to resend all routes with the new cluster ID, you must use the clear ip bgp
  command to perform a hard clear or a soft clear.
- Use the no version to cause BGP to use the router ID as the cluster ID.
neighbor route-reflector-client
- Use to configure the local router as the route reflector and the specified neighbor as one
  of its clients. The reflector and its clients constitute a cluster. BGP neighbors that
  are not specified as clients are nonclients.
- Route reflectors pass routes among the client routers.
- Route reflection eliminates the need for all IBPG peers to be fully–meshed.
  The members of a cluster do not have to be fully meshed, but BGP speakers outside
  the cluster must be fully meshed.
- If client-to-client reflection is enabled (the default), clients of a route reflector cannot
  be members of a peer group.
- If you specify a BGP peer group by using the peerGroupName argument,
  all the members of the peer group inherit the characteristic configured with this command.
  You cannot override this inheritance for a peer group member.
- Changes apply automatically to any routes received after you issue the command.
  To advertise or withdraw routes that are already present in the BGP RIB, you must use
  the clear ip bgp command to issue a hard clear or an outbound soft clear.
- Use the no version to indicate that the neighbor is no longer a client. Use the default version
  to remove the explicit configuration from the peer or
  peer group and reestablish inheritance of the feature configuration.

February 15, 2012 10:20 pm

Tags: Route Reflectors

by admin

BGP – Managing a Large-Scale AS

BGP requires that IBGP peers be fully meshed, creating significant routing overhead as the number of
peers increases. The number of IBGP sessions increases rapidly with the number of routers:

BGP provides two alternative configuration strategies to reduce the number of fully meshed peers.

You can either:

Configure confederations.
Configure route reflectors.

Both of these strategies are complex and can create their own problems. Neither strategy is typically
used unless the mesh of IBGP peers approaches 100 sessions per peer.

Configuring a Confederation

IBGP requires that BGP speakers within an AS be fully meshed. You can reduce the IBGP mesh
inside an AS by subdividing the AS into a confederation of sub-ASs. Each sub-AS must be fully meshed
internally, but the sub-ASs do not have to be fully meshed with each other. Confederations are most useful when the number of IBGP speakers within an AS increases to the
point that each router has about 100 peering sessions.

AS 29 consists of 10 fully meshed IBGP peers (for clarity, only the BGP sessions are shown).
Border router Salem has an EBGP session with a neighbor in AS 325.
Border router Boston hasan EBGP session with a neighbor in AS 413.

Illustrates how you can create three sub-ASs within AS 29 to greatly reduce the number of
peering sessions. According to common practice, use a number from the private range of AS numbers

—from 64512 to 65535—to identify each sub-AS. AS 29 is now a confederation of
three sub-ASs: AS 64720, AS 64721, and AS 64722. Each sub-AS consists of fully meshed IBGP peers.

A slightly modified version of EBGP runs between the sub-ASs: It acts like IBGP within an AS
because the local-pref, MED, and next-hop attributes are preserved across the sub-AS boundaries.
To the external neighbors, AS 29 appears the same as it ever was.

The following commands partially configure router Salem:

router bgp 64720
bgp confederation identifier 29
bgp confederation peers 64721 64722
neighbor 10.2.25.4 remote-as 64720
neighbor 10.2.25.8 remote-as 64721
neighbor 10.2.25.2 remote-as 325

The bgp confederation identifier command establishes router Salem as a member of Confederation 29.
The bgp confederation peers command specifies that sub-AS 64721 and sub-AS 64722 are members
of the same confederation as the sub-AS that includes router Salem.

The neighbor remote-as commands specify the IBGP connection with a neighbor in sub-AS 64720
and the EBGP connections with neighbors in sub-AS 64721 and outside the confederation in AS 325.

Similarly, the following commands partially configure router Harvard:

router bgp 64721
bgp confederation identifier 29
bgp confederation peers 64720 64722
neighbor 10.2.25.7 remote-as 64720

From router Newport’s perspective, router Salem is simply a member of AS 29:

router bgp 325
neighbor 10.2.25.6 remote-as 29

From router Mason’s perspective, router Boston is simply a member of AS 29:

router bgp 413
neighbor 10.3.3.2 remote-as 29

bgp confederation identifier

Use to establish a router as a member of the specified BGP confederation.
To systems outside the confederation, the confederation appears as an autonomous system
with an AS number the same as the confederation identifier.
The new confederation identifier is used in open messages and in the AS path in update messages
that are sent after you issue the command.

To force sessions that are already up to use the new confederation identifier, you must use the clear ip bgp command to perform a hard clear.

bgp confederation peers

Enables EBGP sessions with routers in the peer sub-ASs; the EBGP sessions preserve local-pref,
MED, and next-hop attributes.
You can specify one or more individual sub-AS numbers, or you can issue the filter-list keyword
and an AS-path access list (which is based on regular expressions) to specify a list of sub-AS numbers.
If the remote AS of a peer appears in the specified list of sub-ASs or is identified by the
filter list, then the peer is considered to be in the same confederation.
This command takes effect immediately and bounces only those sessions whose peer type
changed as a result of issuing the command.

February 15, 2012 9:42 am

Tags: bgp confederation

by admin

Cisco: Troubleshooting OSPF and BGP

This document shows how to redistribute Internal BGP routes into OSPF process. Like in other
IGP to IGP redistribution the behavior is different when redistributing IBGP into OSPF.
IBGP learned routes are not forwarded to an IGP routing protocol through the redistribute command.

Use command “bgp redistribute-internal” under the BGP process on the redistributing router.

In the scenario depicted here, router R1 and R2 are running IBGP and router R2/R3 running
OSPF Area 0. R1 is advertising two routes (1.1.1.1 /32 and 172.16.0.0 /16) through network command.
R2 is redistributing BGP into OSPF area 0. It is required to redistribute selected internal routes
(172.16.0.0 /16). The task is achieved by making use of prefix-list and route-map.

A prefix-list, named B2O, is configured on R2 to match the prefix 172.16.0.0

ip prefix-list B2O seq 5 permit 172.16.0.0/16
A route-map, named BGP-To_OSPF, is configured on R2

route-map BGP-To_OSPF permit 10
match ip address prefix-list B2O

In the vrification section, please check the output of “show ip route” command on R3.

Router R1

interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Loopback1
ip address 172.16.1.1 255.255.0.0
!
interface Serial1/0
ip address 192.12.12.1 255.255.255.0
serial restart-delay 0
!
router bgp 100
no synchronization
bgp router-id 1.1.1.1
bgp log-neighbor-changes
network 1.1.1.1 mask 255.255.255.255
network 172.16.0.0
neighbor 192.12.12.2 remote-as 100
no auto-summary

Router R2

interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface Serial1/0
ip address 192.12.12.2 255.255.255.0
serial restart-delay 0
!
interface FastEthernet2/0
ip address 192.23.23.2 255.255.255.0
duplex auto
speed auto
!
router ospf 1
router-id 2.2.2.2
log-adjacency-changes
redistribute bgp 100 metric 100 metric-type 1 subnets route-map BGP-To_OSPF
network 192.23.23.2 0.0.0.0 area 0
!
router bgp 100
no synchronization
bgp router-id 2.2.2.2
bgp log-neighbor-changes
bgp redistribute-internal
neighbor 192.12.12.1 remote-as 100
no auto-summary
!
ip prefix-list B2O seq 5 permit 172.16.0.0/16
!
route-map BGP-To_OSPF permit 10
match ip address prefix-list B2O

Router R3

interface FastEthernet1/0
ip address 192.23.23.3 255.255.255.0
duplex auto
speed auto
!
router ospf 1
log-adjacency-changes
network 192.23.23.3 0.0.0.0 area 0

‘show ip route’ on R3 :

O E1 172.16.0.0/16 [110/101] via 192.23.23.2, 00:57:55, FastEthernet1/0

192.23.23.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.23.23.0/24 is directly connected, FastEthernet1/0

February 14, 2012 12:48 am