Transcript CCNA 3 Module 3 Single

CCNP 1 v3.0 Module 9
BGP
Cisco Networking Academy
© 2003, Cisco Systems, Inc. All rights reserved.
1
Objectives
• Autonomous Systems
• Basic BGP Operation
• Configuring BGP
• Monitoring BGP Operation
• The BGP Routing Process
• BGP Attributes
• The BGP Decision Process
• BGP Route Filtering and Policy Routing
• Redundancy, Symmetry, and Load Balancing
• BGP Redistribution
© 2003, Cisco Systems, Inc. All rights reserved.
2
Overview of Autonomous Systems
© 2003, Cisco Systems, Inc. All rights reserved.
3
Single-homed Autonomous Systems
© 2003, Cisco Systems, Inc. All rights reserved.
4
AS_Path and Private AS Numbers
© 2003, Cisco Systems, Inc. All rights reserved.
5
Multihomed Nontransit Autonomous
Systems
© 2003, Cisco Systems, Inc. All rights reserved.
6
Multihomed Transit Autonomous Systems
© 2003, Cisco Systems, Inc. All rights reserved.
7
When Not to Use BGP
© 2003, Cisco Systems, Inc. All rights reserved.
8
BGP Neighbors
© 2003, Cisco Systems, Inc. All rights reserved.
9
BGP Message Types
•
The Type field can have four values, 1 to
4. Each of these values corresponds to
one of the four BGP message types:
1. Open Message
2. Keepalive Message
3. Notification Message
4. Update Message
© 2003, Cisco Systems, Inc. All rights reserved.
10
Open Message
• Open Message – This message is used to
establish connections with peers and
includes fields for the BGP version
number, the AS number, hold time, and
Router ID.
© 2003, Cisco Systems, Inc. All rights reserved.
11
Keepalive Message
• Keepalive Message – This message type is sent
periodically between peers to maintain
connections and verify paths held by the router
sending the keepalive.
• If the periodic timer is set to a value of zero (0),
no keepalives are sent.
The recommended keepalive interval is one third of the
hold time interval.
The keepalive message is a 19-byte BGP message
header with no data following it.
© 2003, Cisco Systems, Inc. All rights reserved.
12
Notification Message
• Notification Message – This message type
is used to inform the receiving router of
errors.
© 2003, Cisco Systems, Inc. All rights reserved.
13
Update Message
•
•
Update Message – The update messages
contain all the information BGP uses to
construct a loop free picture of the
internetwork.
There are three basic components of an update
message.
1. Network-Layer Reachability Information (NLRI)
2. Path Attributes
3. Withdrawn Routes
© 2003, Cisco Systems, Inc. All rights reserved.
14
BGP Neighbor Negotiation
© 2003, Cisco Systems, Inc. All rights reserved.
15
BGP FSM
• Includes six states:
Idle
Connect
Active
OpenSent
Open Confirm
Established
© 2003, Cisco Systems, Inc. All rights reserved.
16
BGP FSM Idle State
•
Idle is the first state of a BGP connection.
–
BGP is waiting for a Start event, which is normally
initiated by an administrator or a network event; a
Start event is usually caused by an administrator
configuring a BGP session, resetting an already
existing session, or a link coming up across which a
BGP is configured.
–
At the Start event, BGP initializes its resources,
resets a connect retry timer, initiates a TCP
connection, and starts listening for a connection that
may be initiated by a remote peer.
© 2003, Cisco Systems, Inc. All rights reserved.
17
BGP FSM Idle State
• BGP then transitions to a Connect state.
BGP can transition back to Idle from any
other state in case of errors (Notification).
© 2003, Cisco Systems, Inc. All rights reserved.
18
BGP FSM Connect State
•
•
BGP is waiting for the TCP connection to be
completed.
–
If the TCP connection is successful, the state
transitions to OpenSent.
–
If the TCP connection fails, the state transitions to
Active, and the router tries to connect again.
–
If the connect retry timer expires, the state will
remain in the Connect state, the timer will be reset,
and a TCP connection will be initiated.
In case of any other event (initiated by system
or administrator), the state will go back to Idle.
© 2003, Cisco Systems, Inc. All rights reserved.
19
BGP FSM Active State
• BGP is trying to acquire a peer by initiating a
TCP connection.
– If it is successful, it will transition to OpenSent. If the
connect retry timer expires, BGP will restart the
connect timer and fall back to the Connect state.
– While Active, BGP is still listening for a connection
that may be initiated from another peer.
• The state may go back to Idle in case of other
events, such as a stop event initiated by the
system or the operator.
© 2003, Cisco Systems, Inc. All rights reserved.
20
BGP FSM
• In general, a neighbor state that is flipflopping between Connect and Active is
an indication that something is wrong,
and the TCP connection is not taking
effect.
– It could be because of many TCP
retransmissions or the inability of a neighbor
to reach the IP address of its peer.
© 2003, Cisco Systems, Inc. All rights reserved.
21
BGP FSM OpenSent State
• BGP is waiting for an OPEN message from
its peer. The OPEN message is checked
for correctness.
• In case of errors, such as a incompatible
version number or an unacceptable AS,
the system sends an error NOTIFICATION
message and goes back to Idle.
© 2003, Cisco Systems, Inc. All rights reserved.
22
BGP FSM OpenSent State
• If there are no errors, BGP starts sending
KEEPALIVE messages and resets the
KEEPALIVE timer.
© 2003, Cisco Systems, Inc. All rights reserved.
23
BGP FSM OpenSent
• At the OpenSent state, the BGP will recognize
whether the peer belongs to the same AS
(Internal BGP - it is an IBGP peer) or to a
different AS (External BGP - it is an EBGP peer)
by comparing its AS number to the AS number
of its peer.
• When a TCP disconnect is detected, the state
falls back to Active.
– For any other errors, such as an expiration of the hold
timer, BGP will send a NOTIFICATION message with
the corresponding error code and will fall back to the
Idle state.
© 2003, Cisco Systems, Inc. All rights reserved.
24
BGP FSM OpenConfirm
• BGP is waiting for a KEEPALIVE or
NOTIFICATION message.
– If a KEEPALIVE is received, the state will go to
the Established state, and the neighbor
negotiation is complete.
© 2003, Cisco Systems, Inc. All rights reserved.
25
BGP FSM OpenConfirm
• If a NOTIFICATION message is received, the
state falls back to Idle. The system will send
periodic KEEPALIVE messages at the rate set by
the KEEPALIVE timer.
• In case of any TCP disconnect or in response to
any stop event (initiated by the system or the
administrator), the state will fall back to Idle. In
response to any other event, the system will
send a NOTIFICATION message with an FSM
error code and will go back to Idle.
© 2003, Cisco Systems, Inc. All rights reserved.
26
BGP FSM Established State
• Established is the final state in the neighbor
negotiation; BGP starts exchanging UPDATE
packets with its peers.
• Each UPDATE message is checked for errors,
such as missing or duplicate attributes. If errors
are found, a NOTIFICATION is sent to the peer.
• Any NOTIFICATION received while Established
will cause the BGP process to drop the receiving
peer back to Idle.
© 2003, Cisco Systems, Inc. All rights reserved.
27
BGP Message Types
• Type: The type field can have four values
(1-4):
(1) OPEN
(2) UPDATE
(3) NOTIFICATION
(4) KEEPALIVE.
© 2003, Cisco Systems, Inc. All rights reserved.
28
The BGP Open Message
• If two BGP speakers fail to negotiate a
neighbor relationship, they will never
exchange updates.
• Neighbor negotiation is based on the
successful completion of a TCP
connection, the successful processing of
the OPEN message, and periodic
detection of the KEEPALIVE messages.
© 2003, Cisco Systems, Inc. All rights reserved.
29
The BGP Open Message
© 2003, Cisco Systems, Inc. All rights reserved.
30
The BGP Notification Message
• A NOTIFICATION message can close a peering
relationship from any BGP state.
• In the event of a connection failure, you may
need to examine a NOTIFICATION message for
clues about what went wrong.
• The NOTIFICATION message is composed of the
Error Code (8 bits), Error Subcode (8 bits), and a
Data fields (variable length).
© 2003, Cisco Systems, Inc. All rights reserved.
31
The BGP Notification Message
© 2003, Cisco Systems, Inc. All rights reserved.
32
Network-Layer Reachability Information
(NLRI)
Rather than advertise reachable destinations as a network and a subnet mask,
BGP advertises them using network-layer reachability information (NLRI),
which consists of prefixes and prefix lengths.
© 2003, Cisco Systems, Inc. All rights reserved.
33
Path Attributes
© 2003, Cisco Systems, Inc. All rights reserved.
34
Path Attributes
Well-known mandatory
• An attribute that has to exist in the BGP UPDATE
packet. It must be recognized by all BGP
implementations.
• If a well-known attribute is missing, a
notification error will be generated; this ensures
that all BGP implementations agree on a
standard set of attributes.
Examples: AS_PATH, ORIGIN, NEXT_HOP attributes
© 2003, Cisco Systems, Inc. All rights reserved.
35
Path Attributes
Well-known discretionary
• An attribute that is recognized by all BGP
implementations, but may or may not be
sent in the BGP UPDATE message.
Example: LOCAL_PREF, ATOMIC_AGGREGATE
© 2003, Cisco Systems, Inc. All rights reserved.
36
Path Attributes
Optional transitive
• An attribute that may, or may not be,
recognized by all BGP implementations
(thus, optional).
• Because the attribute is transitive, BGP
should accept and advertise the attribute
even if it isn’t recognized.
© 2003, Cisco Systems, Inc. All rights reserved.
37
Path Attributes
Optional non-transitive
• An attribute that may, or may not be,
recognized by all BGP implementations.
• Whether or not the receiving BGP router
recognizes the attribute, it is nontransitive, and should not passed along to
other BGP peers.
© 2003, Cisco Systems, Inc. All rights reserved.
38
Basic BGP Configuration
© 2003, Cisco Systems, Inc. All rights reserved.
39
BGP Operation
• When two routers establish a TCP-enabled
BGP connection between each other, they
are called neighbors or peers.
• Each router running BGP is called a BGP
speaker.
© 2003, Cisco Systems, Inc. All rights reserved.
40
EBGP and IBGP
© 2003, Cisco Systems, Inc. All rights reserved.
41
EBGP and IBGP Configuration Example
© 2003, Cisco Systems, Inc. All rights reserved.
42
Building Peering Sessions
© 2003, Cisco Systems, Inc. All rights reserved.
43
IBGP v EBGP
• When BGP is running inside an AS, it is referred
to as Internal BGP (IBGP).
– If a BGP router’s role is to route IBGP traffic, it is
called a transit router.
• When BGP runs between autonomous systems,
it is called External BGP (EBGP).
– Routers that sit on the boundary of an AS and use
EBGP to exchange information with the ISP are called
border routers.
© 2003, Cisco Systems, Inc. All rights reserved.
44
EBGP v IBGP
• EBGP peers must be directly connected, but there
are certain exceptions to this requirement (mutlihop BGP).
• In contrast, IBGP peers merely require TCP/IP
connectivity within the same AS.
– As long as RTY can communicate with RTW using TCP,
both routers can establish an IBGP session.
– If needed, an IGP such as OSPF can provide IBGP peers
with routes to each other.
• As long as the two BGP routers can reach each
other somehow, they can become BGP neighbors
© 2003, Cisco Systems, Inc. All rights reserved.
45
IBGP
• In a typical configuration, an IBGP router
maintains IBGP sessions with all other IBGP
routers in the AS, forming a logical full-mesh.
– This is necessary because IBGP routers do not
advertise routes learned via IBGP to other IBGP peers
(to prevent routing loops).
– In other words, if you want your IBGP routers to
exchange BGP routes with each other, you should
configure a full-mesh.
– An alternative to this approach: configuring a route
reflector (covered later)
© 2003, Cisco Systems, Inc. All rights reserved.
46
EBGP Multihop
• EBGP neighbors must be directly connected in
order to establish an EBGP session.
• However, EBGP multihop is a Cisco IOS option
allows two routers to be logically connected in
an EBGP session, despite the fact that they are
separated by a router that does not support
BGP.
– The EBGP multihop option is configured on
each peer with the following command:
Router(config-router)#neighbor IP-address ebgp-multihop [hops]
© 2003, Cisco Systems, Inc. All rights reserved.
47
EBGP Multihop and IBGP
© 2003, Cisco Systems, Inc. All rights reserved.
48
EBGP Multihop
RTW(config)#router bgp 200
RTW(config-router)#neighbor 1.1.1.2 remote-as 300
RTW(config-router)#neighbor 1.1.1.2 ebgp-multihop 2
RTU(config)#router bgp 300
RTU(config-router)#neighbor 2.2.2.1 remote-as 200
RTU(config-router)#neighbor 2.2.2.1 ebgp-multihop 2
AS 200
2.2.2.0/30
1.1.1.0/30
AS 300
© 2003, Cisco Systems, Inc. All rights reserved.
49
BGP Operation
• BGP’s job is to exchange routing information
between autonomous systems, while
guaranteeing loop-free path selection.
– BGP4 is the first version of BGP that supports CIDR
and route aggregation.
• BGP does not use technical metrics. Instead,
BGP makes routing decisions based on network
policies.
© 2003, Cisco Systems, Inc. All rights reserved.
50
BGP Operation
• BGP updates are carried using TCP on port 179.
– RIP updates use UDP port 520, while OSPF does not
use a Layer-4 protocol.
• Because BGP requires TCP, IP connectivity must
exist between BGP peers and TCP connections
must be negotiated between them before
updates can be exchanged.
– Thus, BGP inherits TCP’s reliable, connection-oriented
properties.
© 2003, Cisco Systems, Inc. All rights reserved.
51
BGP Operation – AS_PATH
AS Path =
300
200
100
400
500
800
Public AS numbers range between 1 and 64511 and the
private AS numbers between 64512 and 65535.
© 2003, Cisco Systems, Inc. All rights reserved.
52
The AS_Path Attribute
© 2003, Cisco Systems, Inc. All rights reserved.
53
BGP Operation
• The connection between any two systems
forms a path, and the collection of path
information expressed as a sequence of
AS numbers (called the AS_PATH).
• This sequence forms a route to reach a
specific destination.
–All things being equal, BGP prefers routes
with shorter AS paths.
© 2003, Cisco Systems, Inc. All rights reserved.
54
BGP Operation
• Peer routers exchange multiple messages
to open and confirm the connection
parameters, such as the version of BGP to
be used.
• If there are any disagreements between
the peers, notification errors are sent and
the connection fails.
© 2003, Cisco Systems, Inc. All rights reserved.
55
BGP Operation
• When BGP neighbors first establish a
connection, they exchange all candidate BGP
routes. After this initial exchange, incremental
updates are sent as network information
changes.
– Incremental updates are more efficient than complete
table updates.
– Especially true with BGP routers, which may contain
the complete Internet routing table.
© 2003, Cisco Systems, Inc. All rights reserved.
56
Clearing the BGP Table
• BGP can take up to 60 seconds to learn about
configuration changes or topology changes
• To force a change to show up in the BGP table
and therefore in the routing table, you may have
to clear the BGP table after a configuration
change.
Router# clear ip bgp [as number | ip address | *]
© 2003, Cisco Systems, Inc. All rights reserved.
57
Verifying BGP Operation
© 2003, Cisco Systems, Inc. All rights reserved.
58
An Overview of the BGP Routing Process
• Routes are exchanged between BGP peers
by way of update messages
• BGP routers receive the update messages
• BGP routers run some policies or filters
over the updates, and then pass the routes
on to other BGP peers
© 2003, Cisco Systems, Inc. All rights reserved.
59
Implementing Policy
• BGP input and output policies are defined,
generally, using route maps.
• Route maps are used with BGP to control
and modify routing information and to
define the conditions by which routes are
redistributed between routing domains.
© 2003, Cisco Systems, Inc. All rights reserved.
60
The Route Map Command
•
Router(config)#route-map map-tag [permit
| deny] [sequence-number]
– Note that map-tag is a name that identifies
the route map;
– the sequence-number indicates the position
that an instance of the route map is to have
in relation to other instances of the same
route map.
– Instances are ordered sequentially, starting
with the number 10 by default.
© 2003, Cisco Systems, Inc. All rights reserved.
61
An Example Route Map
RTA(config)#route-map MYMAP permit 10
RTA(config-route-map)#match ip address 1
RTA(config-route-map)#set metric 5
RTA(config-route-map)#exit
RTA(config)#access-list 1 permit 1.1.1.0 0.0.0.255
© 2003, Cisco Systems, Inc. All rights reserved.
62
Applying a Route Map to BGP
RTA(config)#router bgp 100
RTA(config-router)#neighbor 172.16.20.2 remote-as 300
RTA(config-router)#neighbor 172.16.20.2 route-map MYMAP out
© 2003, Cisco Systems, Inc. All rights reserved.
63
Implementing BGP Routing Policy
Configuring a Simple Route Map
Applying a Route Map to a BGP Neighbor
© 2003, Cisco Systems, Inc. All rights reserved.
64
Controlling BGP Routing with Attributes
• Common BGP Attributes
Next Hop
AS_Path
Atomic Aggregate
Aggregator
Local Preference
Weight
Multiple Exit Discriminator (MED)
Origin
© 2003, Cisco Systems, Inc. All rights reserved.
65
NEXT_HOP Attribute
• The next hop attribute is a well-known mandatory
attribute, type code 3.
• For EBGP sessions, the next hop is the IP
address of the neighbor that announced the
route.
For routes injected into the AS by way of EBGP, the
next hop learned from EBGP is carried unaltered into
IBGP.
• For IBGP sessions, where routes originated
inside the AS the next-hop is the IP address of the
neighbor that announced the route.
© 2003, Cisco Systems, Inc. All rights reserved.
66
The Next Hop Attribute
© 2003, Cisco Systems, Inc. All rights reserved.
67
BGP Attributes: Next Hop
Next-hop attribute is different for BGP than it is
for the IGPs that we have already learned about
© 2003, Cisco Systems, Inc. All rights reserved.
68
BGP Attributes: Next Hop Example
•
The NEXT_HOP is not necessarily reachable via a direct
connection.
–
RTA’s next-hop for 128.213.1.0/24 is 1.1.1.1, but reaching it
requires a pathway through 3.3.3.3.
•
Thus, the next-hop behavior mandates a recursive IP
routing table lookup for a router to know where to send
the packet.
•
To reach the NEXT_HOP 1.1.1.1, RTA will consult its IGP
routing table to see if, and how, 1.1.1.1 is reachable. This
recursive search continues until the router associates
destination 1.1.1.1 with an outgoing interface.
© 2003, Cisco Systems, Inc. All rights reserved.
69
Next Hop and Multiaccess Nets
• Recall that a network link is considered
multi-access if more than two hosts can
potentially connect to it.
• Routers on a multi-access link share the
same IP subnet, and can physically access
all other connected routers in one hop.
• Ethernet, Frame Relay, and ATM are
examples of multi-access media.
© 2003, Cisco Systems, Inc. All rights reserved.
70
NEXT_HOP Multiaccess
• On a Multiaccess environment such as Ethernet
or Frame Relay, the next hop will be the interface
connected to the media that originated the route.
• The ‘next-hop-self’ keyword forces the
router to advertise itself as the next hop if
needed.
next-hop-self is generally used for NBMA networks
like Frame Relay.
© 2003, Cisco Systems, Inc. All rights reserved.
71
Next Hop and Multiaccess Nets
• BGP speakers always advertise the actual
source of the route if the source is on the
same multi-access link as the speaker.
© 2003, Cisco Systems, Inc. All rights reserved.
72
Next Hop and Multiaccess Nets
Hey, RTA…
BGP Route: 11.11.11.0/24
Next Hop is 10.10.10.3 (RTB)
(not me)
© 2003, Cisco Systems, Inc. All rights reserved.
73
Example Explained
• RTA, RTB, and RTC share a common multiaccess media.
– RTA and RTC are running EBGP, while RTC and RTB
are running OSPF.
– RTC has learned network 11.11.11.0/24 from RTB via
OSPF and is advertising it to RTA via EBGP.
– The correct behavior is for RTA to consider RTB
(10.10.10.3) as the next hop because RTB shares the
same media with RTC.
© 2003, Cisco Systems, Inc. All rights reserved.
74
Next Hop and NBMA
• If the media is broadcast, such as
Ethernet and FDDI, physical connectivity
is a given and the NEXT_HOP behavior is
no problem.
• If the media is non-broadcast, such as
Frame Relay and ATM, problems can
arise.
© 2003, Cisco Systems, Inc. All rights reserved.
75
Next Hop and NBMA
© 2003, Cisco Systems, Inc. All rights reserved.
76
Next Hop and NBMA
• RTA gets a BGP routing update about
11.11.11.0/24 from RTC and would try to
use RTB (10.10.10.3) as the next hop (the
same behavior as on multi-access media).
• Routing will fail because no virtual circuit
exists between RTA and RTB.
© 2003, Cisco Systems, Inc. All rights reserved.
77
Next Hop and NBMA
• Cisco IOS supports a special case
parameter that remedies this situation.
• The ‘next-hop-self’ command
forces the router (in this case, RTC) to
advertise 11.11.11.0/24 with itself as the
next hop (10.10.10.2).
• RTA would then direct its traffic to RTC
to reach destination 11.11.11.0/24.
© 2003, Cisco Systems, Inc. All rights reserved.
78
next-hop-self
Router(config-router)#neighbor IP-address next-hop-self
Soooooooo…
RTC(config-router)#neighbor 10.10.10.1 next-hop-self
© 2003, Cisco Systems, Inc. All rights reserved.
79
The Atomic Aggregate Attribute
© 2003, Cisco Systems, Inc. All rights reserved.
80
The Aggregator Attribute
•
A well-known discretionary attribute, type code 7.
•
Enabling ISP administrators to determine which
BGP router is responsible for a particular instance
of aggregation.
– The AGGREGATOR attribute indicates the local router as
the device that has done the aggregating (summarizing).
•
“I did the aggregating”
– The ATOMIC_AGGREGATE attributes says who did the
aggregating.
•
“He did the aggregating”
© 2003, Cisco Systems, Inc. All rights reserved.
81
ATOMIC_AGGREGATE
• The ATOMIC_AGGREGATE is a well-know
discretionary attribute (type code 6). The
ATOMIC_AGGREGATE attribute is set to
either “True” or “False.”
© 2003, Cisco Systems, Inc. All rights reserved.
82
ATOMIC_AGGREGATE
• If true, this attribute alerts BGP routers that
multiple destinations have been grouped into a
single update.
• In other words, the BGP router that sent the
update had a more specific route to the
destination, but did not send it.
• ATOMIC_AGGREGATE warns receiving routers
that the information they are receiving is not
necessarily the most complete route information
available.
© 2003, Cisco Systems, Inc. All rights reserved.
83
ATOMIC_AGGREGATE
You can manually configure BGP to
summarize routes by using the aggregateaddress command, which has the following
syntax:
Router(config-router)#aggregate-address address mask [as-set]
[summary-only] [suppress-map map-name][advertise-map map-name]
[attribute-map map-name]
© 2003, Cisco Systems, Inc. All rights reserved.
84
ATOMIC_AGGREGATE – Summarization
RTA(config)#router bgp 300
RTA(config-router)#neighbor 3.3.3.3 remote-as 200
RTA(config-router)#neighbor 2.2.2.2 remote-as 100
RTA(config-router)#network 160.10.0.0
RTA(config-router)#aggregate-address 160.0.0.0 255.0.0.0
© 2003, Cisco Systems, Inc. All rights reserved.
85
AGGREGATOR
• AGGREGATOR is a well-known discretionary
attribute (type code 7).
• When configuring address aggregation, you can
also configure the router to include its router ID and
local AS number along with the supernet route.
• This attribute allows ISP administrators to
determine which BGP router is responsible for a
particular instance of aggregation.
• Tracing a supernet to its original “aggregator” may
be necessary for troubleshooting purposes.
© 2003, Cisco Systems, Inc. All rights reserved.
86
LOCAL_PREFERENCE
• Local Preference is a well-known discretionary
attribute, type code 5.
• The Local Preference attribute is a degree of
preference given to a route for comparison with
other routes for the same destination
Higher Local Preference values are preferred.
Local Preference is local to the AS and is exchanged
between IBGP peers only.
© 2003, Cisco Systems, Inc. All rights reserved.
87
The Local Preference Attribute
AS 256
© 2003, Cisco Systems, Inc. All rights reserved.
88
Local Preference Configuration
SanJose(config)#route-map SECONDARY_T1 permit 10
SanJose(config-route-map)#set local-preference 200
SanJose(config-route-map)#exit
SanJose(config)#router bgp 256
SanJose(config-router)#neighbor 192.168.1.5 route-map SECONDARY_T1 in
LA(config)#route-map PRIMARY_T3 permit 10
LA(config-route-map)#set local-preference 300
LA(config-route-map)#router bgp 256
LA(config-router)#neighbor 192.168.1.1 route-map PRIMARY_T3 in
© 2003, Cisco Systems, Inc. All rights reserved.
89
Weight Attribute
• The Weight attribute is similar to the Local
Preference attribute in that it gives higher
preference to the route that has a higher
weight.
• The difference is that the weight parameter
is local to the router and is not exchanged
between routers.
–The weight parameter influences routes
coming from different providers to the same
router
© 2003, Cisco Systems, Inc. All rights reserved.
90
The Weight Attribute
© 2003, Cisco Systems, Inc. All rights reserved.
91
Multi-Exit-Discriminator
• The Multiple-exit-discriminator (MED)
attribute is an optional nontransitive
attribute, type code 4.
• MED informs external neighbors about the
preferred path into an AS that has multiple
entry points.
A lower MED is preferred over a higher MED
• Unlike Local Preference, the MED attribute
is exchanged between autonomous
systems,
© 2003, Cisco Systems, Inc. All rights reserved.
92
The Multiple Exit Discriminator Attribute
© 2003, Cisco Systems, Inc. All rights reserved.
93
MED Configuration Example
RTA will only compare the MED from RTC and RTD b/c
they are from the same autonomous system.
© 2003, Cisco Systems, Inc. All rights reserved.
STOP
94
MED Configuration
RTC(config)#route-map PRIMARY_T1_MED permit 10
RTC(config-route-map)#set Metric 120
RTC(config-route-map)#exit
RTC(config)#router bgp 300
RTC(config-router)#neighbor 192.168.1.5 route-map PRIMARY_T1_MED out
RTD(config)#route-map SECONDARY_T1_MED permit 10
RTD(config-route-map)#set Metric 200
RTD(config-route-map)#exit
RTD(config)#router bgp 300
RTD(config-router)#neighbor 192.168.1.1 route-map SECONDARY_T1_MED out
© 2003, Cisco Systems, Inc. All rights reserved.
95
The Origin Attribute
•
IGP – The prefix is internal to the
originating AS.
•
EGP – The prefix was learned by way of
some EGP, such as BGP.
•
Incomplete – The prefix was learned by
some other means, probably
redistribution.
– well-known mandatory attribute (type code 1)
© 2003, Cisco Systems, Inc. All rights reserved.
96
The ORIGIN attribute
• BGP considers the ORIGIN attribute in its
decision-making process to establish a
preference ranking among multiple routes.
• Specifically, BGP prefers the path with the
lowest origin type, where IGP is lower than
EGP, and EGP is lower than INCOMPLETE.
• Use the set origin route map command
to manipulate the ORIGIN attribute.
© 2003, Cisco Systems, Inc. All rights reserved.
97
Basic Decision Algorithm
Consider only (synchronized) routes with no AS loops
and valid next-hop, then prefer:
Highest WEIGHT
Highest LOCAL PREFERENCE
LOCALLY ORIGINATED (eg network/aggregate)
Shortest AS-PATH
Lowest ORIGIN (IGP < EGP < incomplete)
Lowest MED
EBGP
IBGP
Lowest IGP METRIC to next-hop
Neighbor with lowest ROUTE_ID
Full story see: www.cisco.com/warp/public/459/25.shtml
© 2003, Cisco Systems, Inc. All rights reserved.
98
BGP Decision Making
1.
If the next hop is inaccessible, the route is
ignored (this is why it is important to have an
IGP route to the next hop).
2.
The BGP router will prefer the path with the
largest weight (weight is a Cisco proprietary
parameter).
3.
If the weights are the same, the BGP router will
prefer the route with the largest local
preference.
© 2003, Cisco Systems, Inc. All rights reserved.
99
BGP Decision Making
4.
If the routes have the same local preference,
the BGP router will prefer the route that was
locally originated (originated by this router).
5.
If the local preference is the same, the BGP
router will prefer the route with the shortest
AS_PATH.
6.
If the AS_PATH length is the same, the BGP
router will prefer the route with the lowest
origin type (where IGP is lower than EGP, and
EGP is lower than INCOMPLETE).
© 2003, Cisco Systems, Inc. All rights reserved.
100
BGP Decision Making
7.
If the origin type is the same, the BGP router
will prefer the route with the lowest MED.
8.
If the routes have the same MED, the BGP
router will prefer the route in the following
manner: External (EBGP) is better than
confederation external, which is better than
IBGP. If the AS_PATH length is the same, the
BGP router will prefer the route with the lowest
origin type (where IGP is lower than EGP, and
EGP is lower than INCOMPLETE).
© 2003, Cisco Systems, Inc. All rights reserved.
101
BGP Decision Making
9.
If all the preceding scenarios are identical, the
BGP router will prefer the route that can be
reached via the closest IGP neighbor—that is,
take the shortest internal path inside the AS to
reach the destination (follow the shortest path
to the BGP NEXT_HOP).
10. If the internal path is the same, the BGP router
ID will be a tie breaker. The BGP router will
prefer the route coming from the BGP router
with the lowest router ID. The router ID is
usually the highest IP address on the router or
the loopback address.
© 2003, Cisco Systems, Inc. All rights reserved.
102
The BGP Decision Process
© 2003, Cisco Systems, Inc. All rights reserved.
103
BGP Route Filtering
© 2003, Cisco Systems, Inc. All rights reserved.
104
Using Filters to Implement Routing Policy
•
Two steps in manipulating a route:
1. Identify the network number and subnet
mask of the route to which the policies are
to be applied.
2. Implement the policies, which can be
filtering prefixes out altogether or
manipulating the attributes of a prefix to
influence the routing decision.
© 2003, Cisco Systems, Inc. All rights reserved.
105
BGP Route Filtering
• Route filtering empowers a BGP speaker to
choose what routes to exchange with any of its
BGP peers.
• Route filtering is the cornerstone of policy
routing.
– an AS can identify inbound traffic it is willing to accept
by filtering its outbound advertisements
– an AS can control what routes its outbound traffic
uses by specifying the routes to accept from EBGP
neighbors
© 2003, Cisco Systems, Inc. All rights reserved.
106
BGP Route Filtering
• Even more precise policies can be defined
via route filters.
• For example, BGP routes passing through
a filter can have their attributes
manipulated to affect the best-path
decision process.
© 2003, Cisco Systems, Inc. All rights reserved.
107
Using Distribute-list to Filter BGP Routes
The distribute-list command can be used to filter updates so that
AS3 does not receive transit traffic to network 192.69.10.0 /24.
© 2003, Cisco Systems, Inc. All rights reserved.
108
BGP Route Filtering
• You can apply route filters to or from a
particular neighbor by using the distributelist command.
© 2003, Cisco Systems, Inc. All rights reserved.
109
BGP Route Filtering
RTA(config)#router bgp 3
RTA(config-router)#neighbor 172.16.1.2 remote-as 3
RTA(config-router)#neighbor 172.16.20.1 remote-as 1
RTA(config-router)#neighbor 172.16.20.1 distribute-list 1 out
RTA(config-router)#exit
RTA(config)#access-list 1 deny 192.69.10.0 0.0.0.255
RTA(config)#access-list 1 permit any
© 2003, Cisco Systems, Inc. All rights reserved.
110
BGP Route Filtering
• The distribute-list keyword, used as
part of a BGP neighbor statement, prevents
RTA from advertising prefix 192.69.10.0/24
to RTC.
• An access list is used to identify the
prefixes to be filtered, and the
distribute-list and out keywords
apply the filter to outgoing updates.
© 2003, Cisco Systems, Inc. All rights reserved.
111
BGP Route Filtering
• Whereas configuring BGP neighbor
statements to include the distribute-list
keyword is effective for filtering specific
routes, controlling supernets can be a bit
trickier.
© 2003, Cisco Systems, Inc. All rights reserved.
112
BGP Route Filtering
• Configuring a distribute list relies on
creating an access list.
• If we use a standard access list, we are
afforded only limited functionality.
© 2003, Cisco Systems, Inc. All rights reserved.
113
BGP Route Filtering
• What if you want to advertise an aggregate
address of 172.16.0.0 /16, but not the individual
subnets themselves?
• A standard access list would not work because it
permits more than is desired, since it filters
based on the network address only.
• For example, this access list would permit not
only the 172.16.0.0/16 summary, but also all the
components of that summary as well:
(any route that begins with 172.16.x.x)
access-list 1 permit 172.16.0.0 0.0.255.255
© 2003, Cisco Systems, Inc. All rights reserved.
114
BGP Route Filtering
• To restrict the update to the 172.16.0.0/16
summary, you can use an extended access list.
• In the case of a BGP route filter, an extended list
matches, first, the network address, and second,
the subnet mask of the prefix.
• Both network and mask are paired with their own
wildcard bitmask, using the following syntax:
Router(config)#access-list number permit|deny network
network-wildcard mask mask-wildcard
(both the network number and the subnetmask have a wildcard mask)
© 2003, Cisco Systems, Inc. All rights reserved.
115
BGP Route Filtering
• Using this configuration, RTA would not
send a subnet route (such as 172.16.0.0
/17 or 172.16.10.0 /24) in an update to AS1.
RTA(config)#router bgp 3
RTA(config-router)#neighbor 172.16.1.2 remote-as 3
RTA(config-router)#neighbor 172.16.20.1 remote-as 1
RTA(config-router)#neighbor 172.16.20.1 distribute-list 101 out
RTA(config-router)#exit
RTA(config)#access-list 101 permit ip 172.16.0.0 0.0.255.255
255.255.0.0 0.0.0.0
• It will only send the 172.16.0.0/16 update
© 2003, Cisco Systems, Inc. All rights reserved.
116
BGP Route Filtering
• If using an extended access list to
accomplish this type of filtering seems
confusing to you, you are not alone.
• Improved user-friendliness was one of the
factors that motivated Cisco to include the
ip prefix-list command in IOS 12.0.
© 2003, Cisco Systems, Inc. All rights reserved.
117
BGP Route Filtering
• You can use prefix lists as an alternative to
access lists with many BGP route-filtering
commands.
© 2003, Cisco Systems, Inc. All rights reserved.
118
BGP Route Filtering
• You must define a prefix list before you can
apply it as a route filter. The Cisco IOS allows a
very flexible configuration procedure, where
each statement can be assigned its own
sequence numbers.
• To define a prefix list, use the ip prefix-list
command, which has the following syntax:
Router(config)#ip prefix-list list-name [seq seq-value] deny|permit
network/len [ge ge-value] [le le-value]
© 2003, Cisco Systems, Inc. All rights reserved.
119
BGP Route Filtering
Parameter
Description
list-name
Specifies the name of a prefix list.
seq
deny
(Optional) Applies the sequence number to the
prefix list entry being created or deleted.
(Optional) Specifies the sequence number for the
prefix list entry.
Denies access to matching conditions.
permit
Permits access for matching conditions.
network/len
(Mandatory) The network number and length (in
bits) of the network mask.
(Optional) Applies ge-value to the range specified.
seq-value
ge
ge-value
(Optional) Specifies the lesser value of a range
(the "from" portion of the range description).
le
(Optional) Applies le-value to the range specified.
le-value
(Optional) Specifies the greater value of a range
(the "to" portion of the range description).
© 2003, Cisco Systems, Inc. All rights reserved.
120
BGP Route Filtering
RTA(config)#ip prefix-list ELMO deny 0.0.0.0/0
RTA(config)#ip prefix-list ELMO permit 172.16.0.0/16
RTA(config)#router bgp 100
RTA(config-router)#neighbor 192.168.1.1 remote-as 200
RTA(config-router)#neighbor 192.168.1.1 prefix-list ELMO out
© 2003, Cisco Systems, Inc. All rights reserved.
121
BGP Route Filtering
• The real power of the ip prefix-list
command is in its optional parameters.
• The keywords ge and le can be used to specify
the range of the prefix length to be matched for
prefixes that are more specific than the
network/len value.
• The prefix-length range is assumed to be from
ge-value to 32 if only the ge attribute is
specified, and from len to le-value if only the le
attribute is specified.
© 2003, Cisco Systems, Inc. All rights reserved.
122
le and ge prefix-list options
• For example with only 192.0.0.0/8 le 24,
prefixes from lengths 8 – 24 will be matched
• If we had used only 192.0.0.0/8 ge 25 then
prefixes from lengths 25 – 32 will be
matched
The /8 is essentially ignored when we use ‘ge’
© 2003, Cisco Systems, Inc. All rights reserved.
123
BGP Route Filtering
• As another example, to accept a mask
length of up to 24 bits in routes with the
prefix 192.0.0.0/8, and deny more specific
routes, use the commands as shown in.
RTA(config)#ip prefix-list GROVER permit 192.0.0.0/8 le 24
RTA(config)#ip prefix-list GROVER deny 192.0.0.0/8 ge 25
© 2003, Cisco Systems, Inc. All rights reserved.
124
BGP Route Filtering
• Also the le and ge keywords can be
used together, in the same statement:
RTA(config)#ip prefix-list OSCAR permit 10.0.0.0/8 ge 16 le 24
• This list permits all prefixes in the
10.0.0.0/8 address space that have a
mask of between 16 and 24 bits.
© 2003, Cisco Systems, Inc. All rights reserved.
125
BGP Route Filtering
• The prefix list NOSUBNETS denies mask
lengths greater than 25 bits in all address
space In other words, any prefix with a
length greater than 24 bits will be matched
and denied.
RTA(config)#ip prefix-list NOSUBNETS deny 0.0.0.0/0 ge 25
• The NO10NET prefix list will match and
deny any route in the 10.0.0.0/8 address
space.
RTA(config)#ip prefix-list NO10NET deny 10.0.0.0/8 le 32
© 2003, Cisco Systems, Inc. All rights reserved.
126
BGP Route Filtering
• Each prefix list entry is assigned a
sequence number, either by default or
manually by an administrator.
• By numbering the prefix list statements,
new entries can be inserted at any point in
the list, which is important because
routers test for prefix list matches from
lowest sequence number to highest.
© 2003, Cisco Systems, Inc. All rights reserved.
127
BGP Route Filtering
RTA#show ip prefix-list
ip prefix-list ELMO: 3 entries
seq 5 deny 0.0.0.0/0
seq 10 permit 172.16.0.0/16
seq 15 permit 192.168.0.0/16 le 24
© 2003, Cisco Systems, Inc. All rights reserved.
128
The ip prefix-list command
© 2003, Cisco Systems, Inc. All rights reserved.
129
Example ip prefix-list Configuration
© 2003, Cisco Systems, Inc. All rights reserved.
130
Redundancy, Symmetry, and Load Balancing
• Redundancy is achieved by providing multiple
alternate paths for the traffic.
This occurs by having multiple connections to one or
more autonomous systems.
• Symmetry is achieved when traffic leaving the
AS from one exit point comes back through the
same point
• Exists if an AS maintains a single connection to
outside networks
© 2003, Cisco Systems, Inc. All rights reserved.
131
Redundancy, Symmetry, and Load
Balancing
© 2003, Cisco Systems, Inc. All rights reserved.
132
Issues with Redundancy, Symmetry, and Load
Balancing
• If an AS has many different links to the outside
world, traffic tends to flow asymmetrically.
• An asymmetrical traffic flow can result in
increased delay and other routing problems.
In addition, customers and providers like to see their
traffic come back the same way that it left the AS.
• To promote symmetry, choose a primary path
and configure routing policies that force traffic to
flow along this path.
To force traffic to leave the AS by way of a particular
path, use LOCAL_PREFERENCE to force traffic to enter
the AS by the same path, use MED.
© 2003, Cisco Systems, Inc. All rights reserved.
133
Issues with Redundancy, Symmetry, and
Load Balancing
© 2003, Cisco Systems, Inc. All rights reserved.
134
Default Routing in BGP Networks
• To provide redundancy, default information could
be received from multiple BGP sources.
• In a BGP system, the Local Preference attribute
can be manipulated on the various default
routes.
• This is so that one default route is identified as a
primary, the highest Local Preference, and others
are kept as backups.
© 2003, Cisco Systems, Inc. All rights reserved.
135
Default Routing in BGP Networks
© 2003, Cisco Systems, Inc. All rights reserved.
136
Load Balancing
© 2003, Cisco Systems, Inc. All rights reserved.
137
Load Balancing
• If there are two default routes and one is used as
the primary route and one is used as the backup
then for outbound traffic, load balancing is not
an option.
• However, for inbound traffic the customer can
influence the routing decisions made by the ISP
by manipulating the metrics advertised to the
ISP.
The lowest metric will be preferred (MED configured
using a route map).
© 2003, Cisco Systems, Inc. All rights reserved.
138
Multihomed Connections with a Single
Provider
© 2003, Cisco Systems, Inc. All rights reserved.
139
Load Balancing to Different Providers
• What if this customer were multihomed to two
different providers?
The customer could control inbound traffic the same
way, by manipulating advertised metrics using a route
map.
As for outbound traffic, the customer either can
configure static default routes to the two providers or
can dynamically learn a default route from both
providers.
For static default routes, the administrative distance
can be used to prefer one default route over the other,
while one dynamically learned route can be preferred
using the Local Preference attribute.
© 2003, Cisco Systems, Inc. All rights reserved.
140
Multihomed Scenarios with a Multiple
Provider
© 2003, Cisco Systems, Inc. All rights reserved.
141
BGP Redistribution Overview
© 2003, Cisco Systems, Inc. All rights reserved.
142
Injecting Information Statically into BGP
© 2003, Cisco Systems, Inc. All rights reserved.
143
Injecting Information Statically into BGP
• Information can be injected into BGP
dynamically or statically.
• Statically injected routes are constantly
maintained by the BGP routing tables,
regardless of the status of the networks
that they identify.
• A dynamic advertisement will end if the
network being advertised no longer exists,
a static advertisement will not.
© 2003, Cisco Systems, Inc. All rights reserved.
144
Injecting Information Dynamically into BGP
• Dynamically injected routes come and go from
the BGP routing table, depending on the status
of the networks that they identify.
• A dynamic advertisement will end if the network
being advertised no longer exists in the routing
table.
• Dynamically injected information can be further
divided into purely dynamic redistribution or
semi-dynamic redistribution.
© 2003, Cisco Systems, Inc. All rights reserved.
145
Injecting Information Dynamically into BGP
• For purely dynamic redistribution, all the
IGP routes are redistributed into BGP
using the ‘redistribute’ command.
• For semi-dynamic redistribution, only
certain IGP routes are to be injected into
BGP using the BGP network command.
© 2003, Cisco Systems, Inc. All rights reserved.
146
Redistribution Issues
• Mutual redistribution between IGP and BGP can also result in
the propagation of flawed routing information.
With mutual redistribution, an EBGP route that was injected
from the outside into the AS will be redistributed into the IGP
and propagated within the AS.
However, because the IGP is redistributing into BGP the original
external route could be sent back into BGP by way of the IGP as
if it originated from inside the AS.
• To remedy these situations, special filtering should be put on
the border routers to specify what particular networks should
be injected from the IGP into BGP.
For protocols that differentiate between internal and external
routes, such as OSPF, configure the IGP to ensure that it will
redistribute only internal routes into BGP.
© 2003, Cisco Systems, Inc. All rights reserved.
147
BGP Redistribution Configuration Example
For example, a network learned via BGP from AS 100 should show up as
external to OSPF and should not be redistributed back into BGP from OSPF.
© 2003, Cisco Systems, Inc. All rights reserved.
148
Redistribution Issues
• In the Cisco implementation, external
OSPF routes are automatically blocked
from being redistributed into BGP.
• Certain protocols may not distinguish
between internal and external routes, such
as RIP or IGRP.
For these protocols, you should use route
filters such as distribute lists and prefix lists.
© 2003, Cisco Systems, Inc. All rights reserved.
149
Scaling BGP
•
Autonomous systems consisting of hundreds
of BGP routers can pose a serious
management problem.
•
If that many Internal BGP (IBGP) speakers are
configured as a logical full mesh, BGP
operation becomes extremely complex.
–
Imagine a network where over 100 neighbor
statements are required just to define the remote-as
of each peer!
© 2003, Cisco Systems, Inc. All rights reserved.
150
Route Reflector (RR)
• recent addition to BGP (IOS 11.1)
• offers an alternative to the logical full-mesh
requirement of IBGP.
• acts as a focal point for IBGP sessions.
Multiple BGP routers can peer with a central point (the
RR), rather than peer with every other router in a full
mesh.
similar to OSPF’s DR/BDR feature
• provides large ISPs with added BGP scalability.
© 2003, Cisco Systems, Inc. All rights reserved.
151
Route Reflector (RR)
• The use of route reflectors is recommended
only for autonomous systems that support a
large internal BGP mesh, on the order of
more than 100 sessions per router.
– introduces processing overhead on the
routers that act as route reflectors
– if configured incorrectly, can cause routing
loops and instability.
© 2003, Cisco Systems, Inc. All rights reserved.
152
Route Reflector (RR)
IBGP routers
are typically
fully meshed.
© 2003, Cisco Systems, Inc. All rights reserved.
153
Route Reflector (RR)
Route Reflector Server
Route Reflector Client
© 2003, Cisco Systems, Inc. All rights reserved.
A route reflector
can be configured
so that IBGP routers
don’t have to be in a
full mesh to
completely
exchange routing
information.
154
Route Reflector (RR)
• RTA receives an update from an external
peer and passes it on to RTB, which is
configured as a route reflector server with
two clients, RTA and RTC.
• RTB will reflect the update from client RTA
to client RTC.
© 2003, Cisco Systems, Inc. All rights reserved.
155
Route Reflector (RR)
• The IBGP peers of a route reflector fall under two
categories: clients and nonclients.
• A route reflector and its clients form a cluster.
• All IBGP peers of the route reflector that are not
part of the cluster are nonclients and must be
fully meshed to all other nonclients and RR
servers.
Never configure route reflector clients to peer with IBGP
speakers outside their cluster.
© 2003, Cisco Systems, Inc. All rights reserved.
156
Route Reflector (RR)
• Clients and nonclients don’t even know
that route reflection is occurring. To
identify clients and clusters, use the
neighbor command, which has the
following syntax, on the route reflector
server:
Router(config-router)#neighbor IP-address route-reflector-client
© 2003, Cisco Systems, Inc. All rights reserved.
157
Route Reflector (RR)
© 2003, Cisco Systems, Inc. All rights reserved.
158
Route Reflector (RR)
Configuring a RR server:
RTB(config)#router bgp 100
RTB(config-router)#neighbor 1.1.1.1 remote-as 100
RTB(config-router)#neighbor 1.1.1.1 route-reflector-client
RTB(config-router)#neighbor 2.2.2.2 remote-as 100
RTB(config-router)#neighbor 2.2.2.2 route-reflector-client
RTB(config-router)#neighbor 4.4.4.4 remote-as 100
RTB(config-router)#neighbor 7.7.7.7 remote-as 100
RTB(config-router)#neighbor 8.8.8.8 remote-as 200
© 2003, Cisco Systems, Inc. All rights reserved.
159
Route Reflector (RR)
Configuring a RR client:
RTA(config)#router bgp 100
RTA(config-router)#neighbor 3.3.3.3 remote-as 100
© 2003, Cisco Systems, Inc. All rights reserved.
160
Route Reflector (RR)
• When the route reflector receives an advertised
route, depending on the neighbor, it does the
following:
A route from an external BGP speaker is advertised to all
clients and nonclient peers.
A route from a nonclient peer is advertised to all clients.
A route from a client is advertised to all clients and
nonclient peers. Hence, the clients need not be fully
meshed.
© 2003, Cisco Systems, Inc. All rights reserved.
161
Route Reflector (RR)
© 2003, Cisco Systems, Inc. All rights reserved.
162
Summary
• The details of the practical implementation for BGP
as part of the overall design problem in building
reliable Internet connectivity was covered.
• Specific attributes of BGP and how the attributes are
applied individually and together address this design
problem.
• The terminology, attributes, and details of this
module are specific to BGP.
• The general concepts and problems raised are
pertinent to routing architecture design, regardless
of what specific protocols are being utilized.
© 2003, Cisco Systems, Inc. All rights reserved.
163