1/26/96-Rev: A1.2 Page 5 Sam Halabi-cisco Systems
2.0 EBGP and IBGP
If an Autonomous System has multiple BGP speakers, it could be used as a
transit service for other ASs. As you see below, AS200 is a transit
autonomous system for AS100 and AS300.
It is necessary to ensure reachability for networks within an AS before
sending the information to other external ASs. This is done by a
combination of Internal BGP peering between routers inside an AS and by
redistributing BGP information to Internal Gateway protocols running in
the AS.
As far as this paper is concerned, when BGP is running between
routers belonging to two different ASs we will call it EBGP (Exterior
BGP) and for BGP running between routers in the same AS we will call it
IBGP (Interior BGP).
AS100
AS200
AS300
EBGP
IBGP
1/26/96-Rev: A1.2 Page 6 Sam Halabi-cisco Systems
3.0 Enabling BGP routing
Here are the steps needed to enable and configure BGP.
Let us assume you want to have two routers RTA and RTB talk BGP. In the
first example RTA and RTB are in different autonomous systems and in the
second example both routers belong to the same AS.
We start by defining the router process and define the AS number that the
routers belong to:
The command used to enable BGP on a router is:
router bgp
autonomous-system
RTA#
router bgp 100
RTB#
router bgp 200
The above statements indicate that RTA is running BGP and it belongs to
AS100 and RTB is running BGP and it belongs to AS200 and so on.
The next step in the configuration process is to define BGP neighbors.
The neighbor definition indicates which routers we are trying to talk to
with BGP.
The next section will introduce you to what is involved in forming a
valid peer connection.
1/26/96-Rev: A1.2 Page 7 Sam Halabi-cisco Systems
3.1 BGP Neighbors/Peers
Two BGP routers become neighbors or peers once they establish a TCP
connection between one another. The TCP connection is essential in order
for the two peer routers to start exchanging routing updates.
Two BGP speaking routers trying to become neighbors will first bring up
the TCP connection between one another and then send open messages in
order to exchange values such as the AS number, the BGP version they are
running (version 3 or 4), the BGP router ID and the keepalive hold time,
etc. After these values are confirmed and accepted the neighbor
connection will be established. Any state other than established is an
indication that the two routers did not become neighbors and hence the
BGP updates will not be exchanged.
The neighbor command used to establish a TCP connection is:
neighbor
ip-address
remote-as
number
The remote-as number is the AS number of the router we are trying to
connect to via BGP.
The ip-address is the next hop directly connected address for EBGP
1
and
any IP address
2
on the other router for IBGP.
It is essential that the two IP addresses used in the neighbor command of
the peer routers be able to reach one another. One sure way to verify
reachability is an extended ping between the two IP addresses, the
extended ping forces the pinging router to use as source the IP address
specified in the neighbor command rather than the IP address of the
interface the packet is going out from.
1.A special case (EBGP multihop) will be discussed later when the external BGP peers are not
directly connected.
2.A special case for loopback interfaces is discussed later.
1/26/96-Rev: A1.2 Page 8 Sam Halabi-cisco Systems
It is important to reset the neighbor connection in case any bgp
configuration changes are made in order for the new parameters to take
effect.
clear ip bgp
address
(where address is the neighbor address)
clear ip bgp * (clear all neighbor connections)
By default, BGP sessions begin using BGP Version 4 and negotiating
downward to earlier versions if necessary. To prevent negotiations and
force the BGP version used to communicate with a neighbor, perform the
following task in router configuration mode:
neighbor {
ip address
|
peer-group-name
} version
value
An example of the neighbor command configuration follows:
RTA#
router bgp 100
neighbor 129.213.1.1 remote-as 200
RTB#
router bgp 200
neighbor 129.213.1.2 remote-as 100
neighbor 175.220.1.2 remote-as 200
RTC#
router bgp 200
neighbor 175.220.212.1 remote-as 200
AS100
AS200
AS300
EBGP
IBGP
RTA
RTB
RTC
RTD
175.220.212.1
175.220.1.2
129.213.1.2
129.213.1.1
1/26/96-Rev: A1.2 Page 9 Sam Halabi-cisco Systems
In the above example RTA and RTB are running EBGP. RTB and RTC are run-
ning IBGP. The difference between EBGP and IBGP is manifested by having
the remote-as number pointing to either an external or an internal AS.
Also, the EBGP peers are directly connected and the IBGP peers
are not. IBGP routers do not have to be directly connected, as long as
there is some IGP running that allows the two neighbors to reach one
another.
The following is an example of the information that the command
“sh ip bgp neighbors” will show you, pay special attention to the BGP
state. Anything other than state established indicates that the peers are
not up. You should also note the BGP is version 4, the remote router ID
(highest IP address on that box or the highest loopback interface in case
it exists) and the table version (this is the state of the table. Any
time new information comes in, the table will increase the version and a
version that keeps incrementing indicates that some route is flapping
causing routes to keep getting updated).
#SH IP BGP N
BGP neighbor is 129.213.1.1, remote AS 200, external link
BGP version 4, remote router ID 175.220.212.1
BGP state = Established, table version = 3, up for 0:10:59
Last read 0:00:29, hold time is 180, keepalive interval is 60 seconds
Minimum time between advertisement runs is 30 seconds
Received 2828 messages, 0 notifications, 0 in queue
Sent 2826 messages, 0 notifications, 0 in queue
Connections established 11; dropped 10
In the next section we will discuss special situations such as EBGP
multihop and loopback addresses.
1/26/96-Rev: A1.2 Page 10 Sam Halabi-cisco Systems
4.0 BGP and Loopback interfaces
Using a loopback interface to define neighbors is commonly used with IBGP
rather than EBGP. Normally the loopback interface is used to make sure
that the IP address of the neighbor stays up and is independent of an
interface that might be flaky. In the case of EBGP, most of the time the
peer routers are directly connected and loopback does not apply.
If the IP address of a loopback interface is used in the neighbor com-
mand, some extra configuration needs to be done on the neighbor router.
The neighbor router needs to tell BGP that it is using a loopback
interface rather than a physical interface to initiate the BGP neighbor
TCP connection. The command used to indicate a loopback interface is:
neighbor
ip-address
update-source
interface
The following example should illustrate the use of this command.
RTA#
router bgp 100
neighbor 190.225.11.1 remote-as 100
neighbor 190.225.11.1 update-source int loopback 1
RTB#
router bgp 100
neighbor 150.212.1.1 remote-as 100
In the above example, RTA and RTB are running internal BGP inside
autonomous system 100. RTB is using in its neighbor command the
loopback interface of RTA (150.212.1.1); in this case RTA has to force
BGP to use the loopback IP address as the source in the TCP neighbor
connection. RTA will do so by adding the update-source int loopback
configuration (neighbor 190.225.11.1 update-source int loopback 1) and
this statement forces BGP to use the IP address of its loopback
interface when talking to neighbor 190.225.11.1.
AS100
RTA
RTB
190.225.11.1
Loopback Interface 1
150.212.1.1
1/26/96-Rev: A1.2 Page 11 Sam Halabi-cisco Systems
Note that RTA has used the physical interface IP address (190.225.11.1)
of RTB as a neighbor and that is why RTB does not need to do any
special configuration.
5.0 EBGP Multihop
In some special cases, there could be a requirement for EBGP speakers to
be not directly connected. In this case EBGP multihop is used to allow
the neighbor connection to be established between two non directly con-
nected external peers. The multihop is used only for external BGP and not
for internal BGP. The following example gives a better illustration of
EBGP multihop.
RTA#
router bgp 100
neighbor 180.225.11.1 remote-as 300
neighbor 180.225.11.1 ebgp-multihop
RTB#
router bgp 300
neighbor 129.213.1.2 remote-as 100
RTA is indicating an external neighbor that is not directly connected.
RTA needs to indicate that it will be using ebgp-multihop. On the other
hand, RTB is indicating a neighbor that is directly connected
(129.213.1.2) and that is why it does not need the ebgp-multihop command.
Some IGP or static routing should also be configured in order to allow
the non directly connected neighbors to reach one another.
The following example shows how to achieve load balancing with BGP in a
particular case where we have EBGP over parallel lines.
AS100
RTA
129.213.1.2
AS300
RTB
180.225.11.1
129.213.1.3
1/26/96-Rev: A1.2 Page 12 Sam Halabi-cisco Systems
5.1 EBGP Multihop (Load Balancing)
RTA#
int loopback 0
ip address 150.10.1.1 255.255.255.0
router bgp 100
neighbor 160.10.1.1 remote-as 200
neighbor 160.10.1.1 ebgp-multihop
neighbor 160.10.1.1 update-source loopback 0
network 150.10.0.0
ip route 160.10.0.0 255.255.0.0 1.1.1.2
ip route 160.10.0.0 255.255.0.0 2.2.2.2
RTB#
int loopback 0
ip address 160.10.1.1 255.255.255.0
router bgp 200
neighbor 150.10.1.1 remote-as 100
neighbor 150.10.1.1 update-source loopback 0
neighbor 150.10.1.1 ebgp-multihop
network 160.10.0.0
ip route 150.10.0.0 255.255.0.0 1.1.1.1
ip route 150.10.0.0 255.255.0.0 2.2.2.1
The above example illustrates the use of loopback interfaces,
update-source and ebgp-multihop. This is a workaround in order to achieve
load balancing between two EBGP speakers over parallel serial lines. In
normal situations, BGP will pick one of the lines to send packets on and
load balancing would not take place. By introducing loopback interfaces,
the next hop for EBGP will be the loopback interface. Static routes (it
could be some IGP also) are used to introduce two equal cost paths to
reach the destination. RTA will have two choices to reach next hop
160.10.1.1: one via 1.1.1.2 and the other one via 2.2.2.2 and the same
for RTB.
AS 100
AS 200
150.10.0.0
160.10.0.0
RTA
RTB
loopback 150.10.1.1
loopback 160.10.1.1
1.1.1.1 1.1.1.2
2.2.2.1 2.2.2.2
1/26/96-Rev: A1.2 Page 13 Sam Halabi-cisco Systems
6.0 Route Maps
At this point I would like to introduce route maps because they will be
used heavily with BGP. In the BGP context, route map is a method used to
control and modify routing information. This is done by defining condi-
tions for redistributing routes from one routing protocol to another or
controlling routing information when injected in and out of BGP. The for-
mat of the route map follows:
route-map
map-tag
[[permit | deny] | [
sequence-number
]]
The map-tag is just a name you give to the route-map. Multiple instances
of the same route map (same name-tag) can be defined. The sequence number
is just an indication of the position a new route map is to have in the
list of route maps already configured with the same name.
For example, if I define two instances of the route map, let us call it
MYMAP, the first instance will have a sequence-number of 10, and the
second will have a sequence number of 20.
route-map MYMAP permit 10
(first set of conditions goes here.)
route-map MYMAP permit 20
(second set of conditions goes here.)
When applying route map MYMAP to incoming or outgoing routes, the first
set of conditions will be applied via instance 10. If the first set of
conditions is not met then we proceed to a higher instance of the route
map.
The conditions that we talked about are defined by the match and set
configuration commands. Each route map will consist of a list of match
and set configuration. The match will specify a match criteria and set
specifies a set action if the criteria enforced by the match command are
met.
For example, I could define a route map that checks outgoing updates and
if there is a match for IP address 1.1.1.1 then the metric for that
update will be set to 5. The above can be illustrated by the following
commands:
match ip address 1.1.1.1
set metric 5
Now, if the match criteria are met and we have a permit then the routes
will be redistributed or controlled as specified by the set action and we
break out of the list.
If the match criteria are met and we have a deny then the route will not
be redistributed or controlled and we break out of the list.
1/26/96-Rev: A1.2 Page 14 Sam Halabi-cisco Systems
If the match criteria are not met and we have a permit or deny then the
next instance of the route map (instance 20 for example) will be checked,
and so on until we either break out or finish all the instances of the
route map. If we finish the list without a match then the route we are
looking at will not be accepted nor forwarded.
One restriction on route maps is that when used for filtering BGP updates
(as we will see later) rather than when redistributing between protocols,
you can NOT filter on the inbound when using a “match” on the ip address.
Filtering on the outbound is OK.
The related commands for match are:
match as-path
match community
match clns
match interface
match ip address
match ip next-hop
match ip route-source
match metric
match route-type
match tag
The related commands for set are:
set as-path
set automatic-tag
set community
set clns
set interface
set default interface
set ip next-hop
set ip default next-hop
set ip precedence
set tos
set level
set local-preference
set metric
set metric-type
set next-hop
set origin
set tag
set weight
Let’s look at some route-map examples:
Không có nhận xét nào:
Đăng nhận xét