BGP 4

BGP 4
BGP Training © 2002, Cisco Systems, Inc. 1

Agenda (I)
• IGP vs. EGP

• BGP Basic Concepts
• Peering
• Attributes
• BGP Multiprotocol
Juniper Business Use
BGP Training © 2002, Cisco Systems, Inc. Only 2
Agenda (II)
• The Path Selection Algorithm

• BGP Configurations
• Originating BGP Routes
• More Details and Knobs

Agenda (III)
• Scaling BGP
Confederations
Route Reflectors
Peer-groups
• Conclusion

IGP vs. EGP
And the winner is …

IGP/EGP
• Interior Gateway Protocol

• Routes toward internal prefixes
• Which is the interface/next-hop closest to a given
prefix?
We need to define a metric for each route
• Exterior Gateway Protocol
• Protocol to glue routing information between
different ASes

BGP Basic Concepts
Let’s the fun get started …

What Does BGP Route?
• BGP routes between ASes

AS: numbering range form 1 to 65,535
Private range: 64512 - 65535
• For BGP, the Internet topology is just
a collection of Ases
• BGP = path vector protocol

Path Vector Protocol (II)
I prepend my AS AS 4
321
to outgoing
421
updates
21
PATH
AS 3
1
21
AS 1 AS 2
168.1.1.0 /24

Nomenclature
• In a prefix 64.96.0.0 /16 :

Network: 64.96.0.0
Prefix length: 16
Mask: 255.255.0.0
• NLRI (network Layer Reachability
Information):
It is just a prefix that is reachable
eBGP vs. iBGP
• Communication between ASes is

thanks to eBGP (external BGP)
• But an AS can have many routers,
how do they communicate updates
between them?
iBGP (internal BGP) !!!

eBGP vs. iBGP
iBGP eBGP iBGP
iBGP iBGP
iBGP eBGP
iBGP

eBGP vs. iBGP
• Rules of propagation:
eBGP learned -> propagate to iBGP, eBGP
iBGP learned -> propagate to eBGP
• Never propagate iBGP->iBGP

We do not have a loop protection
mechanism between iBGP sessions
Other BGP Particularities
• Each prefix has associated a set of

attributes
To choose best route
To modify propagation of routes
• POLICY:
Filter prefixes
check & modify attributes
Peering
Hello my friend, something new?

A BGP Session
• Neighbors must be configured

explicitly
• Runs over TCP (179)

Number Of Hops Considerations
• iBGP peers:
Can be any number of hops away
TTL=255 in BGP packets header
• eBGP peers: (default)
According to rfc, it must be 1 hop away
TTL=1 in BGP packets header

eBGP Multihop
neighbor {neighbor}
ebgp-multihop [maximum-hop-count]
• Will overcome the eBGP hops restrictions

Connected check is ignored
• maximum-hop-count is the TTL in ip packets
(default 255)
Remember: no ebgp-multihop = {TTL=1}
• With maximum-hop-count > 1 is possible to set
Remember that if there is any router between the
two peers it stills needs to know the routes.

BGP Messages. Message Types
• OPEN – Establish a peering session

• UPDATE – Announcing new routes or withdrawing
previously announced routes.
• Announcement = prefix + attribute values
• NOTIFICATION – Shuts down a peering session.
• KEEP-ALIVE – Handshake at regular intervals
• ROUTE REFRESH - The messages contain a request
for the peer to resend its routes to the system, ex
apply new policies. # clear ip bgp <prefix> soft in/out

BGP Messages
OPEN (V)
• CAPABILITY NEGOTIATION
• Current Capabilities
1: Multiprotocol (rfc2858)
2: Route Refresh (rfc2918)
3: Outbound Route Filter (ORF)
(draft-ietf-idr-route-filter-14)
4: Multi-prefix/MPLS label (rfc3107)
64: Graceful restart
128: Route Refresh (OLD CODE)
129: ORF (12.0S,12.0T)
130: ORF (other releases)
128-255: Vendor specific

Basic Configuration
Lo0: 1.1.1.1/32
Lo0: 1.1.1.2/32
.2
.1 192.0.1.0/24
Dst IP: 1.1.1.2 Dst IP: 1.1.1.1

Src IP: 1.1.1.1 Src IP: 1.1.1.2
AS: A AS: B
router bgp A Note: If A ≠ B we also

neighbor 1.1.1.2 remote-as B need ebgp-multihop!
neighbor 1.1.1.2 update-source LoopBack0
router bgp B
neighbor 1.1.1.2 remote-as A
neighbor 1.1.1.2 update-source LoopBack0
Finite State Machine (III)
• Everything happens between each pair of neighbors
• Debugs: debug ip bgp
• Idle—The router is searching the routing table to see whether a route
exists to reach the neighbor.
• Connect—The router found a route to the neighbor and has
completed the three-way TCP handshake.
• Active- If the router is in the active state, this means that it has found
the IP address in the neighbor statement and has created and sent
out a BGP open packet but has not received a response (open
confirm packet) back from the neighbor.
• Open sent—An open message was sent, with the parameters for the
BGP session.
• Open confirm—The router received agreement on the parameters for
establishing a session. Alternatively, the router goes into Active state
if there is no response to the open message.
• Established—Peering is established and routing begins.
Finite State Machine
Active State Timers
Closing
*Mar 24 18:49:48.907: BGP: 14.1.1.2 went from Established to Idle
Wait 20 seconds
*Mar 24 18:50:09.503: BGP: 14.1.1.2 went from Idle to Active
*Mar 24 18:50:09.515: BGP: 14.1.1.2 open active, delay 23712ms
Wait 23712 ms (30 secs – 50% jitter)
*Mar 24 18:50:33.255: BGP: 14.1.1.2 open active, local address 14.1.1.1
*Mar 24 18:51:03.347: BGP: 14.1.1.2 open failed: Connection timed out; remote host not responding
TCP session failed. Wait ConnectRetry timer (120 seconds)
TCP session is finally successful an BGP peer comes up
*Mar 24 18:58:03.631: BGP: 14.1.1.2 went from Active to OpenSent
*Mar 24 18:58:03.767: BGP: 14.1.1.2 went from OpenSent to OpenConfirm
*Mar 24 18:58:03.839: BGP: 14.1.1.2 went from OpenConfirm to Established
*Mar 24 18:58:03.839: %BGP-5-ADJCHANGE: neighbor 14.1.1.2 Up

Finite State Machine
Debugs (II)
ACTIVE SIDE
16:06:30: BGP: 7.72.6.1 sending OPEN, version 4
16:06:31: BGP: 7.72.6.1 OPEN rcvd, version 4
16:06:31: BGP: 7.72.6.1 rcv OPEN w/ OPTION parameter len: 12
16:06:31: BGP: 7.72.6.1 rcv OPEN w/ option parameter type 2 (Capability) len 6
16:06:31: BGP: 7.72.6.1 OPEN has CAPABILITY code: 1, length 4
16:06:31: BGP: 7.72.6.1 OPEN has MP_EXT CAP for afi/safi: 1/1
PASSIVE SIDE
16:06:31: BGP: 7.75.7.1 passive open
16:06:31: BGP: 7.75.7.1 OPEN rcvd, version 4
16:06:31: BGP: 7.75.7.1 sending OPEN, version 4
16:06:31: BGP: 7.75.7.1 rcv OPEN w/ OPTION parameter len: 12
16:06:31: BGP: 7.75.7.1 OPEN has MP_EXT CAP for afi/safi: 1/1

Attributes
A prefix just as I like it …

Attribute Format
4 Types of Attributes (I)
• Well-known: known by all

implementations
1. mandatory: must be present in an
update
2. discretionary: does not have to be
present in an update

Attribute Format
4 Types of Attributes (II)
• Optional: a BGP implementation may

not know about it
3. transitive: if unrecognized, pass it
along to other BGP speakers & set the
PARTIAL BIT
4. non-transitive: if unrecognized, do not
pass it along

ORIGIN (type code 1)
• Well known-mandatory, 1 octet

• Informative of how the route was
originated (but it’s often changed by
policies)
• It is one of this values:
0: IGP (i): with the network command
1: EGP (e): from EGP !!
2: INCOMPLETE (?): from another protocol

AS_PATH (type code 2) (I)
• Well known-mandatory
• Information of all the ASes the route
traversed
• It is a sequence of AS path segments:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------
| Path Seg Type |Path Seg Length| Path Seg Value (...)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------

NEXT_HOP (type code 3) (I)
• Well-known mandatory
• It is an IP address
• Propagates only inside the AS
• It is the next-hop where to send the
packets that match this prefix
It does not need to be directly connected!
We will do a recursive lookup for the next-hop
Typically, the next-hop is known via the IGP
NEXT_HOP (type code 3) (II)
• Set the NEXT_HOP in updates sent to

eBGP peers:
Usually to our peering address
• In updates sent to iBGP peers,
NEXT_HOP does not change

NEXT_HOP (type code 3) (III)
192.0.1.0 /24
170.0.0.1
180.0.0.1
NEXT_HOP: 170.0.0.1
NEXT_HOP: 170.0.0.1
BGP: 192.0.1.0 /24: GW=170.0.0.1 (NEXT_HOP)

IGP: 170.0.0.1 /32: GW=180.0.0.1
FORWARDING: RECURSIVE LOOKUP
192.0.1.0 /24 -> 180.0.0.1
MULTI_EXIT_DISC (MED)
(type code 4) (I)
• Optional non-transitive, 4 octets

Exception: sent to eBGP peers if we originated
the route locally
Sends information about the proximity of
the prefix
• If MED is missing, it is assumed MED=0
If bgp bestpath missing-as-worst then it is
assumed the MAXIMUM value
MULTI_EXIT_DISC (MED)
(type code 4) (II)
192.0.1.0 /24
MED = 10
MED 20
Route with
lowest MED
wins!!
LOCAL_PREF (MED)
(type code 5) (I)
• Well-known discretionary, 4 octets

Never over EBGP
Always over IBGP
• It is set to give an administrative
degree of preference for incoming
routes
LOCAL_PREF
(type code 5) (II)
• Default value is 100

Or configured:
bgp default local-preference <default-loc-pref>
set outbound in IBGP when it is not

received from eBGP

LOCAL_PREF (type code 5) (III)
LOC_PREF = {EMPTY} = 100
192.0.1.0 /24
LOC_PREF = 100
set via policy:

LOC_PREF = 200 LOC_PREF = 200
Route with
highest
LOC_PREF wins!!
ATOMIC_AGGREGATE
(type code 6)
• Well-known discretionary, 0 octets!

• Added if the route is originated by an
aggregation AND the AS-PATH
information is lost
• Just informative purposes

AGGREGATOR (type code 7)
• Optional transitive, 6 octets

• If the route is originated by aggregation:
added by the router that did the aggregation
• It is “AS + IP address”
• Just informative purposes

COMMUNITY (type code 8) (I)
• rfc1997
• Optional transitive
• Community: a 4 octet tag (color) to
identify the route
• A route may have multiple
communities
The attribute is a set of 4 byte values
• Facilitates the use of policies
COMMUNITY (type code 8) (II)
• Representation of each community:

(1) 0xXXXXXXXX or (2) 0xYYYY:ZZZZ
YYYYY is usually the AS that defines ZZZZ
For (2):
ip bgp-community new-format
• FFFF:xxxx and 0000:xxxx are reserved

COMMUNITY (type code 8) (III)
• Especial communities:
0xFFFFFF01: NO_EXPORT
Do not advertise the route outside the AS
0xFFFFFF02: NO_ADVERTISE
Do not advertise the route to any peer
0xFFFFFF03: LOCAL_AS (or NO_EXPORT_SUBCONFED)
Do not advertise outside the Local-AS (Local-AS is a
sub-AS if you are using confederations)
0x0: INTERNET
“Represents” all routes

COMMUNITY (type code 8) (IV)
• Cisco configuration:
neighbor x.x.x.x send-community
To send already existing communities
To allow sending policy set communities
Otherwise, you never send any community
• Cisco implementation:
We show and propagate communities in order (lower to
higher) and eliminating repetitions

EXTENDED COMMUNITY
(type code 16) (I)
draft-ietf-idr-bgp-ext-communities
rfc4360
• Differences with COMMUNITY:
8 octets
2 fields: type + value
Regular type TYPE VALUE

Depending in
high-order TYPE
octet
Extended type TYPE VALUE

EXTENDED COMMUNITY
(type code 16) (II)
High-order TYPE field octet
FORMAT for TEMPLATE extended types
Structure of VALUE field

Transitive bit:
0 community transitive across ASes
1 community NON-transitive across ASes
IANA authority bit:
0 IANA assignable
1 vendor-specific type
EXTENDED COMMUNITY
(type code 16) (III)
TEMPLATE extended types
Type Value
AS format 0x00 AS 32 bit value

Supported
IP-address format 0x01 IP address 16 bit value
Long-AS format 0x02 4 octets AS 16 bit value
Opaque 0x03 48 bit value
• HIGH-ORDER TYPE OCTECT

IANA assignable
Or 0x40,0x41,0x42,0x43 if NON-transitive
Global Local
administrator administrator
•HIGH-ORDER TYPE OCTECT: sub-TYPES sub-field sub-field
Define the meaning of value

EXTENDED COMMUNITY
(type code 16) (IV)
Type Used Name Standards Type characteristics
0x0001,0x0101, Route origin rfc4360,rfc2547 VPN of Obsolete, not used
0x0201 Origin
0x0002,0x0102, Route target rfc4360,rfc2547,rfc4364, 0x0002,0x0102,0x0202 IANA

0x0202 (RT) draft-rekhter-as4octet-ext-
community
0x0003,0x0103, Site of origin rfc4360, rfc4364 Route 0x0003,0x0103,0x0203 IANA
0x0203 (SOO) Origin, draft-rekhter-
as4octet-ext-community
0x0006 Link bandwidth draft-ietf-idr-bgp-ext- We set AS=0
communities-08 (obsolete,
uses type=0x0004)
0x0005, 0x0105, OSPF domain rfc4577 0x0005,0x0105 IANA; 0x8000 Cisco;
all 4 supported
0x0205, 0x8000 ID
0x8000 OSPF route efc4577 (uses 0x0306 IANA
type type=0x0306) TEMPLATE for rfc type
0x8001 OSPF Router rfc4577 (uses 0x0107 IANA

ID type=0x0107) TEMPLATE for rfc type
By default : TRANSITIVE and TEMPLATE
EXTENDED COMMUNITY
(type code 16) (V)

0x0008, 0x0208 BGP Data rfc4384 0x0008 IANA
Collection NOT used by Cisco
0x0008, 0x0108 Multicast-VPN draft-rosen-vpn-mcast

Control group
0x0009, 0x0109 Multicast-VPN draft-rosen-vpn-mcast
Data group
0x0300,0x0301, L2VPN-ID encoded draft-ietf-l2vpn- 0x0300,0x0301,0x0302 IANA

as route dstiguisher signaling
0x0302 type (01,02,03) NOT used by Cisco
non-TEMPLATE
0x4301 Cost draft-retana-bgp- non-TRANSITIVE
custom-decision
Community
CSCdu53928

EXTENDED COMMUNITY
(type code 16) (VI)

EIGRP route CSCds09932 non-TEMPLATE
0x8800 information appended
EIGRP route metric CSCds09932 non-TEMPLATE

0x8801 information

0x8802 information Vector:
Reliability + Hop + BW

0x8803 information System:
Reserve + Load + MTU
EIGRP route external CSCds09932 non-TEMPLATE

0x8804 information System:
Remote AS + Remote
ID
EIGRP route external CSCds09932 non-TEMPLATE
0x8805 information Remote:
Protocol + Metric

EXTENDED COMMUNITY
(type code 16) (VII)
• Comparison
When comparing extended communities, all 8 bytes must
be compared
The type, the subtype does ALWAYS differentiate the
extended communities
• Cisco implementation:
We show and propagate extended communities in order
(lower to higher) and eliminating repetitions
When it’s a well known community, we show the name,
otherwise we show the numerical value

WEIGHT
• Cisco specific
• Pseudo-attribute
Never propagates out of the router
• Value: 0 - 65535
• Default:
originated locally: WEIGHT= 32768
other: WEIGHT= 0
Show ip bgp
• To list ALL the routes in the BGP table

routerA#show ip bgp
BGP table version is 3, local router ID is 1.1.1.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

*> 5.5.5.2/32 192.0.0.2 0 0 3 10 11 i
*> 9.9.9.9/32 192.0.2.4 0 0 4 10 10 i
* 192.0.0.2 0 0 3 10 11 i
* 192.0.1.3 0 0 3 10 10 i

show ip bgp <network>/<pl-short>
longer-prefixes
• To list ALL the routes whose prefix is a subset of
<network>/<pl-short>
prefix-length ≥ pl-short
R1#sh ip bgp 8.8.8.0/25 longer-prefixes
R1#sh ip bgp 8.8.8.0 255.255.255.0 longer-prefixes


*> 8.8.8.0/24 0.0.0.0 0 32768 i
R1#sh ip bgp 8.8.8.0 255.255.0.0 longer-prefixes


*> 8.8.0.0/16 0.0.0.0 0 32768 i
*> 8.8.8.0/24 0.0.0.0 0 32768 i

show ip bgp <network>/<pl-long>
shorter-prefixes [<pl-short>]
• To list ALL the routes whose prefix is a superset of
<network>/<pl-long>
pl-long > prefix-length > pl-short
(default pl-short= 0; 0.0.0.0/0 never listed)
R1#sh ip bgp 8.8.8.0/32 shorter-prefixes

*> 8.8.0.0/16 0.0.0.0 0 32768 i
*> 8.8.8.0/24 0.0.0.0 0 32768 i
R1#sh ip bgp 8.8.8.0/25 shorter-prefixes 16

*> 8.8.8.0/24 0.0.0.0 0 32768 i
R1#sh ip bgp 8.8.8.0/25 shorter-prefixes 15

*> 8.8.0.0/16 0.0.0.0 0 32768 i
*> 8.8.8.0/24 0.0.0.0 0 32768 i

Show ip bgp <network> [<mask>]
• To see all the attributes of a prefix
routerA#show ip bgp 160.100.0.0 255.255.0.0

BGP routing table entry for 160.100.0.0/16, version 12
Paths: (2 available, best #2, advertised over EBGP)
3
204.146.33.66 from 204.146.33.66 (204.146.33.2)
Origin IGP, metric 20, localpref 100, valid, internal
1
204.146.33.10 from 204.146.33.10 (204.146.33.1)
Origin IGP, metric 0, localpref 100, valid, internal, best

BGP Multiprotocol
Why only one?

Motivation
• BGP works well for IPv4 Interdomain Routing:

Let’s use it for other addresses families
Each address family is defined by:
AFI (Address Family Indentifier)
SAFI (Subsequent AFI)
• Examples:
AFI: IPv4, IPv6
SAFI: unicast, multicast, VPNv4
• Extensions by rfc2858
More Addresses?
• The router needs at least one IPv4

address
For peering
For BGP identifier
• Information that needs to change to a
non IPv4 AFI:
NLRI
NEXT_HOP
New Attributes (I)
• How to encode the new information?

Same update message
Add all additional information in new attributes
• We just need 2 new attributes:
MP_REACH_NLRI (type 14)
reachable addresses + next-hop
MP_UNREACH_NLRI (type 15)
unreachable addresses
Both optional non-transitive

AFIs and SAFIs
• AFI (rfc1700)
1 IPv4
2 IPv6
3 CLNS
8 E.164
• Subsequent-AFI (Sub-AFI or SAFI)

for IPv4:
0 Reserved
1 Unicast
2 Multicast
3 Unicast + Multicast
4 Label
64 Tunnel
128-255 Vendor specific
128 VPN

Wireshark to capture the MP-BGP VPNv4 updates sent for
prefix 20.0.15/24

The Path Selection
Algorithm
One route to rule them all…

Steps
Reachable Routes
1. Only consider paths with reachable

NEXT_HOP (NOT-CONSIDERED)
2. Do not consider PATH if not
synchronized (NOT-CONSIDERED)
(if synchronization is enabled, iBGP paths
need to have another IGP in the RIB
to be synchronized)

Steps
Administrative Preference
3. Highest WEIGHT
Local to the router
4. Highest LOCAL_PREF
Local to the AS

Steps
Metric in ASes
5. locally originated route
Originated in this router
And better via network command than via
aggregate command
6. Shortest AS_PATH
Like a global metric: 1 AS = 1 hop
AS_SET counts as 1
AS_CONFED_SEQ does not count
6a. If bgp bestpath as-path ignore skip this step

Steps
Remote Metric
7. Lowest ORIGIN code:

IGP < EGP< incomplete (or ‘?’)
How far is the route in the LAST AS

Steps
Near Metric (I)
8. Lowest MULTI_EXIT_DISC (MED)

Indicates IGP distance in the next AS
8a IF bgp deterministic-med, order the

candidate paths by AS before
comparing (it should always be
configured!)

Steps
Near Metric (II)
8b IF bgp always-compare-med, then

compare MED for all paths
ELSE consider only if paths are
from the same neighbor AS
AS_CONFED_XXX is ignored
8c IF bgp bestpath med-confed compare
also the paths with only
AS_CONFED_XXX
Steps
Near Metric (III)
9. Prefer External path over Internal

path
Confederation-eBGP = Internal
10. Lowest IGP metric to NEXT_HOP

Steps
Breaking Ties (I)
11. For eBGP paths

11a. IF bgp bestpath compare-routerid, skip
this step
11b. ELSE select oldest
Introduced by CSCdk12061 (12.0(1))
11c. IF multipath enabled, install up to

N parallel paths
maximum-paths [ibgp] N
Steps
Breaking Ties (II)
12. Lowest Router-ID

(use Originator-ID instead if present)
13. Shortest Cluster-List
(if present)
14. Lowest neighbor IP address

Steps
All The Knobs
synchronization (default ON)
neighbor {neighbor} ebgp-multihop 1 (default ON)
CSCdi22799 (10.0(5)S) for TTL option
maxas-limit {<MAX-ASes>} (default OFF)
CSCdr54230 (12.0(12)S); CSCdv46892 also INVALID (12.0(21)S)
bgp bestpath as-path ignore (default OFF) CSCdj85999 (11.1(20)CC)
bgp deterministic-med (default OFF) CSCdi69580 (11.1(8)CA)
bgp always compare-med (default OFF) CSCdi23980 (10.2(2))
bgp bestpath med missing-as-worst (default OFF) CSCdj85999 (11.1(20)CC)
bgp bestpath med-confed (default OFF) CSCdj85999 (11.1(20)CC)
bgp bestpath compare-routerid (default OFF)
CSCdk12061, CSCdk23201 (11.1(20)CC) to do the OFF behavior default
CSCdr47086 (12.0(11)S,12.1(3)) adds the knob
maximum-paths [iBGP] {max-paths} (default OFF)
CSCdj85999 (11.1(1)) eBGP; CSCdp72929 (12.2(2)T) iBGP
BGP Configurations
… for your BGP construction kit

Full Mesh (I)
• All the routers in an AS run iBGP

sessions between all them
• N routers: O(NxN) iBGP sessions!
There are some scalability problems
• Why full mesh?
Remember: iBGP learned routes are not
propagated towards iBGP peers
Full Mesh (II)
AS 2
AS 100
AS 3
iBGP update
eBGP eBGP update
iBGP
Physical link
Full Mesh (III)
• Remember: attributes not modified by

iBGP
NEXT_HOP, LOCAL_PREF, MED remain
Unless explicit policies are configured
• Best practice:
iBGP peering with loopback addresses
If interfaces go down, you do not loose your
peering sessions

Synchronization
[no] synchronization
• Requires for an iBGP route to be in the RIB to be

consider as valid (i.e. considered as a best path
candidate)
• Default ON
Just for historic reasons !!
Best practice: Configure always no synchronization
Default changed to OFF in CSCdu81680 (12.0(21)ST)

Synchronization
• An iBGP route learned route is only considered

valid (synchronized) if the prefix is also learned
through an IGP
And only then it can be advertised (to eBGP peers)
We check the routing table for the IGP prefix (we never
see a route in the RIB installed by iBGP)
• This check makes sure that routes will not be
dropped in the (non-BGP) forwarding path

Synchronization
AS 690
AS 880
Synchronization:
IGP -> BGP
AS 209
BGP session
iBGP route propagation B does not
eBGP route propagation Redistribution:
run BGP
eBGP-> IGP
IGP route propagation
• Router A won’t advertise the BGP prefixes

from AS209 to AS690router till the IGP
converges
Synchronization
• Usually, not a good idea to

redistribute BGP into IGP
• But If you do not redistribute, all your
routes will be not synchronized!
• SOLUTION: Turn synchronization off:
no synchronization
(common practice)
Label Switching (I)
• A better way to not run BGP in the

core, only in the border routers
In the border router, BGP will know an
IGP prefix for the NEXT_HOP of a BGP
prefix
This IGP prefix will have a LABEL
associated
The BGP prefix will have assigned also
this LABEL

Label Switching (II)
BGP: 40.0.0.1 /16 2. To reach
AS 690 192.0.1.1,
C sets LABEL =3
AS 880
192.0.1.1,
advertised AS 209
to AS 880 LABEL= 1
IGP LABEL=3
4. A removes the 3. B does not run BGP,

label and forwards but it switches labels: 1. Normal IP
normal IP LABEL 3 -> LABEL 1 forwarding:
40.0.0.1/16 has
BGP session NEXT_HOP =192.0.1.1
iBGP route propagation
eBGP route propagation
LABEL path

Miscellaneous
• local-as - Prepends both incoming and
outgoing updates.
• no-prepend - Do not prepend local-as to
updates coming in from ebgp peers
• replace-as - Replace real AS with local AS in
the EBGP updates
• Dual-as Any AS is acceptable i.e. either with
local-as or original as
• Allowas-in
• As-ovrride.

Originating BGP Routes
Routes do not come from Paris...
BGP Training © 2002, Cisco Systems, Inc. www.cisco.com 84

How to Inject a prefix in BGP
• Network command - network, mask must match

exactly to an IGP route in the routing table
• redistribute command
• aggregate-address

Aggregating
aggregate-address <network> <mask>

[summary-only] [as-set]
[advertise-map <adv-rm-name>]
[suppress-map <supress-map-name>]
[route-map|attribute-map <rm-name>]
• Creates a less specific route (AGGREGATE)
• The components must exist in the BGP
table
49.0.2.0 /24
aggregate-address
49.0.1.0 /24 49.0. 0.0 /16
49.1.0.0 /22 49.0.0.0 255.0.0.0
Route Reflectors
A game of mirrors

Motivation
• Scalability
• rfc4456, rfc2796, rfc1996
• Reduce the number of BGP peering
sessions in an AS
• How?
Change the rules of propagation for iBGP
routes

Reflection of Routes
AS 2 AS 2
AS 1 AS 1
Classic iBGP mesh Router A becomes a route-reflector
3 iBGP sessions Routes reflected from A to B

2 iBGP sessions
Normal iBGP session
A is a route reflector
Route Reflector iBGP
session B,C are route reflector clients of A
Configuration
• In the route-reflector, we configure who is a

route reflector client:
neighbor <neighbor> route-reflector-client
• Note: the route reflector client does not

know it is a route reflector client
• Definition of a reflected route: route that
doesn’t follow usual rules of propagation

Rules Of Propagation of Updates
Learned by Propagated to
eBGP, local eBGP Like

iBGP clients usually
iBGP non-clients
iBGP non-client iBGP clients
iBGP client Reflected

iBGP clients
iBGP non-clients

Clusters
• Cluster:
set of route-reflectors + its clients
In our definition, we assume that any router (route-reflector or
client) can belong to only one cluster as a route-reflector or as a
client.
In an unorthodox configuration, the cluster definition would
loose meaning.
• CLUSTER-ID
ROUTER-ID by default
or cluster-id <cluster-id >
Only route-reflectors in a cluster know what is the cluster-id

New Attributes (I)
• Objective:
Avoid loops of routing information
(it would happen in a miss-configuration)
Avoid useless replication of updates
• Two new attributes:
ORIGINATOR (type code 9)
CLUSTER_LIST (type code 10)
(both are optional non-transitive)
Route Reflectors Caveats
• When you reflect a route: you do not change

the attributes
Outbound policies, next-hop-self have no
effect
• The Cluster List and Originator ID are both
optional non-transitive BGP attributes, which
means they are removed at the border of an
autonomous system and should never be
advertised to any eBGP peers.

Conclusion (II)
Know your BGP !!


BGP 4

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BGP 4

Uploaded by

Copyright:

Available Formats

BGP 4

BGP Training © 2002, Cisco Systems, Inc. 1

• IGP vs. EGP

• The Path Selection Algorithm

Juniper Business Use

Juniper Business Use

And the winner is …

BGP Training © 2002, Cisco Systems, Inc. 5

• Interior Gateway Protocol

Juniper Business Use

Let’s the fun get started …

BGP Training © 2002, Cisco Systems, Inc. 7

• BGP routes between ASes

Juniper Business Use

Juniper Business Use

• In a prefix 64.96.0.0 /16 :

• Communication between ASes is

Juniper Business Use

iBGP eBGP iBGP

Juniper Business Use

• Never propagate iBGP->iBGP

• Each prefix has associated a set of

Hello my friend, something new?

BGP Training © 2002, Cisco Systems, Inc. 15

• Neighbors must be configured

Juniper Business Use

Juniper Business Use

• Will overcome the eBGP hops restrictions

Juniper Business Use

• OPEN – Establish a peering session

Juniper Business Use

128-255: Vendor specific

Dst IP: 1.1.1.2 Dst IP: 1.1.1.1

router bgp A Note: If A ≠ B we also

Juniper Business Use

Juniper Business Use

A prefix just as I like it …

BGP Training © 2002, Cisco Systems, Inc. 25

• Well-known: known by all

Juniper Business Use

• Optional: a BGP implementation may

Juniper Business Use

• Well known-mandatory, 1 octet

Juniper Business Use

Juniper Business Use

• Set the NEXT_HOP in updates sent to

Juniper Business Use

BGP: 192.0.1.0 /24: GW=170.0.0.1 (NEXT_HOP)

• Optional non-transitive, 4 octets

• Well-known discretionary, 4 octets

• Default value is 100

set outbound in IBGP when it is not

Juniper Business Use

set via policy:

• Well-known discretionary, 0 octets!

Juniper Business Use

• Optional transitive, 6 octets

Juniper Business Use

• Representation of each community:

Juniper Business Use

Juniper Business Use

Juniper Business Use

Regular type TYPE VALUE