Professional Documents
Culture Documents
Providers
Presentation Slides
Will be available on
ftp://ftp-eng.cisco.com
/pfs/seminars/NANOG50-BGP-Techniques.pdf
And on the NANOG 50 website
Conference
Conference
BGP Basics
What is BGP?
Conference
Described in RFC4271
RFC4276 gives an implementation report on BGP
RFC4277 describes operational experiences using BGP
Conference
Conference
Usage:
0 and 65535
1-64495
64496-64511
64512-65534
23456
65536-65551
65552-4294967295
(reserved)
(public Internet)
(documentation - RFC5398)
(private use only)
(represent 32-bit range in 16-bit world)
(documentation - RFC5398)
(public Internet)
See www.iana.org/assignments/as-numbers
Conference
BGP Basics
Peering
A
AS 100
AS 101
D
AS 102
Conference
AS 100
DMZ
Network
AS 101
D
AS 102
Shared network between ASes
Conference
10
Conference
11
eBGP used to
exchange prefixes with other ASes
implement routing policy
Conference
12
eBGP
Conference
eBGP
eBGP
iBGP
iBGP
iBGP
iBGP
IGP
IGP
IGP
IGP
AS1
AS2
AS3
AS4
13
AS 100
AS 101
14
Conference
15
D
Topology independent
Each iBGP speaker must peer with every other iBGP
speaker in the AS
Conference
16
17
BGP Attributes
Conference
18
AS-Path
Sequence of ASes a
route has traversed
Used for:
AS 200
AS 100
170.10.0.0/16
180.10.0.0/16
Loop detection
Applying policy
AS 300
AS 400
150.10.0.0/16
AS 500
Conference
180.10.0.0/16
170.10.0.0/16
150.10.0.0/16
19
AS-PATH length
maintained
AS 300
AS 80000
AS 70000
170.10.0.0/16
180.10.0.0/16
AS 400
150.10.0.0/16
AS 90000
Conference
180.10.0.0/16
170.10.0.0/16
150.10.0.0/16
20
AS 100
170.10.0.0/16
180.10.0.0/16
140.10.0.0/16
170.10.0.0/16
AS 300
500 300
500 300 200
140.10.0.0/16
AS 500
180.10.0.0/16
170.10.0.0/16
140.10.0.0/16
Conference
180.10.0.0/16 is not
accepted by AS100 as the
prefix has AS100 in its ASPATH this is loop
detection in action
21
Next Hop
150.10.1.1
AS 200
150.10.0.0/16
150.10.1.2
iBGP
A
eBGP
AS 300
150.10.0.0/16 150.10.1.1
160.10.0.0/16 150.10.1.1
AS 100
160.10.0.0/16
Conference
22
iBGP
Loopback
120.1.254.2/32
Loopback
120.1.254.3/32
AS 300
D
A
120.1.1.0/24 120.1.254.2
120.1.2.0/23 120.1.254.3
23
150.1.1.1
150.1.1.2
150.1.1.3
B
120.68.1.0/24
AS 201
Conference
24
Conference
25
Conference
26
Origin
Conveys the origin of the prefix
Historical attribute
Used in transition from EGP to BGP
Conference
27
Aggregator
Conveys the IP address of the router or BGP speaker
generating the aggregate route
Optional & transitive attribute
Useful for debugging purposes
Does not influence best path selection
Conference
28
Local Preference
AS 100
160.10.0.0/16
AS 200
AS 300
D
500
800
A
160.10.0.0/16
> 160.10.0.0/16
500
800
AS 400
C
Conference
29
Local Preference
Non-transitive and optional attribute
Local to an AS non-transitive
Default local preference is 100 (Cisco IOS)
Conference
30
120.68.1.0/24
> 120.68.1.0/24
AS 200
2000
1000
120.68.1.0/24
2000
120.68.1.0/24
1000
B
120.68.1.0/24
AS 201
Conference
31
Multi-Exit Discriminator
Inter-AS non-transitive & optional attribute
Used to convey the relative preference of entry points
determines best path for inbound traffic
Conference
32
Multi-Exit Discriminator
metric confusion
MED is non-transitive and optional attribute
Some implementations send learned MEDs to iBGP peers by
default, others do not
Some implementations send MEDs to eBGP peers by default,
others do not
Conference
33
Community
Communities are described in RFC1997
Transitive and Optional Attribute
32 bit integer
Represented as two 16 bit integers (RFC1998)
Common format is <local-ASN>:xx
0:0 to 0:65535 and 65535:0 to 65535:65535 are reserved
34
Community Example
(before)
ISP 2
X
100.10.0.0/16
permit 100.10.0.0/16 in
AS 400
ISP 1
AS 300
C
permit 160.10.0.0/16 in
AS 100
160.10.0.0/16
Conference
permit 170.10.0.0/16 in
AS 200
170.10.0.0/16
35
Community Example
(after)
ISP 2
160.10.0.0/16
170.10.0.0/16
300:1
300:1
100.10.0.0/16
100.10.0.0/16
300:9
AS 400
ISP 1
AS 300
160.10.0.0/16
300:1
AS 100
160.10.0.0/16
Conference
170.10.0.0/16
300:1
AS 200
170.10.0.0/16
36
Well-Known Communities
Several well known communities
www.iana.org/assignments/bgp-well-known-communities
no-export
65535:65281
no-advertise
65535:65282
no-export-subconfed
65535:65283
no-peer
65535:65284
37
No-Export Community
105.7.0.0/16
105.7.X.X
No-Export
105.7.X.X
AS 100
B
C
AS 200
105.7.0.0/16
38
No-Peer Community
105.7.0.0/16
105.7.X.X
No-Peer
upstream
C&D&E are
peers e.g.
Tier-1s
105.7.0.0/16
C
A
upstream
upstream
39
Community
Implementation details
Community is an optional attribute
Some implementations send communities to iBGP peers by
default, some do not
Some implementations send communities to eBGP peers by
default, some do not
Conference
40
Conference
41
Conference
42
Conference
43
Conference
44
Conference
45
Conference
46
Conference
47
Conference
48
Conference
49
BGP Capabilities
Extending BGP
Conference
50
BGP Capabilities
Documented in RFC2842
Capabilities parameters passed in BGP open message
Unknown or unsupported capabilities will result in
NOTIFICATION message
Codes:
0 to 63 are assigned by IANA by IETF consensus
64 to 127 are assigned by IANA first come first served
128 to 255 are vendor specific
Conference
51
BGP Capabilities
Current capabilities are:
0
Reserved
[RFC3392]
[RFC4760]
[RFC2918]
[RFC5291]
[RFC3107]
[RFC5549]
64
[RFC4724]
65
[RFC4893]
66
Deprecated
67
[ID]
68
Multisession BGP
[ID]
69
[ID]
See www.iana.org/assignments/capability-codes
Conference
52
BGP Capabilities
Multiprotocol extensions
This is a whole different world, allowing BGP to support more
than IPv4 unicast routes
Examples include: v4 multicast, IPv6, v6 multicast, VPNs
Another tutorial (or many!)
Conference
53
Conference
54
Conference
55
Conference
56
Conference
57
Dynamic Reconfiguration
Route Refresh
Conference
58
Route Refresh
BGP peer reset required after every policy change
Because the router does not store prefixes which are rejected
by policy
Conference
59
Conference
60
Dynamic Reconfiguration
Use Route Refresh capability if supported
find out from the BGP neighbour status display
Non-disruptive, Good For the Internet
61
Route Reflectors
Conference
62
n=1000 nearly
half a million
ibgp sessions!
13 Routers
78 iBGP
Sessions!
Two solutions
Route reflector simpler to deploy and run
Confederation more complex, has corner case advantages
Conference
63
AS 100
B
Conference
64
Route Reflector
Reflector receives path from
clients and non-clients
Clients
A
B
Reflectors
C
Non-meshed clients
Described in RFC4456
Conference
AS 100
65
Conference
66
Cluster_list attribute
The local cluster-id is added when the update is sent by the RR
Best to set cluster-id is from router-id (address of loopback)
(Some ISPs use their own cluster-id assignment strategy but
needs to be well documented!)
Conference
67
Conference
68
PoP3
AS 100
PoP1
PoP2
Cluster One
Cluster Two
Conference
69
Conference
70
Conference
71
Conference
72
AS 100
AS 200
C
D
F
73
BGP Confederations
Conference
74
Confederations
Divide the AS into sub-AS
eBGP between sub-AS, but some iBGP information is kept
Preserve NEXT_HOP across the
sub-AS (IGP carries this information)
Preserve LOCAL_PREF and MED
Conference
75
Confederations (Cont.)
Visible to outside world as single AS Confederation
Identifier
Each sub-AS uses a number from the private AS range (6451265534)
Conference
76
Confederations
Sub-AS
65530
A
Sub-AS
65532
C
AS 200
Sub-AS
65531
B
77
Confederations: AS-Sequence
180.10.0.0/16
200
Sub-AS
65002
180.10.0.0/16
180.10.0.0/16
{65002} 200
Sub-AS
65004
H
Sub-AS
65003
180.10.0.0/16
Conference
E
F
100
Sub-AS
65001
Confederation
100
200
78
Conference
79
RRs or Confederations
Multi-Level
Hierarchy
Policy
Control
Scalability
Migration
Complexity
Anywhere
Confederations
in the
Network
Yes
Yes
Medium
Medium
to High
Anywhere
in the
Network
Yes
Yes
Very High
Very Low
Internet
Connectivity
Route
Reflectors
Most new service provider networks now deploy Route Reflectors from Day One
Conference
80
Conference
81
Conference
82
32-bit ASNs
Standards documents
Description of 32-bit ASNs
www.rfc-editor.org/rfc/rfc4893.txt
Textual representation
www.rfc-editor.org/rfc/rfc5396.txt
New extended community
www.rfc-editor.org/rfc/rfc5668.txt
Conference
83
32-bit ASNs
Refers to the range 65536 to 4294967295
(or the extended range)
Conference
84
Conference
85
Representation
Representation of 0-4294967295 ASN range
Most operators favour traditional format (asplain)
A few prefer dot notation (X.Y):
asdot for 65536-4294967295, e.g 2.4
asdot+ for 0-4294967295, e.g 0.64513
But regular expressions will have to be completely rewritten for
asdot and asdot+ !!!
For example:
^[0-9]+$ matches any ASN (16-bit and asplain)
This and equivalents extensively used in BGP multihoming
configurations for traffic engineering
Conference
^([0-9]+)|([0-9]+\.[0-9]+)$
^[0-9]+\.[0-9]+$
86
Changes
32-bit ASNs are backward compatible with 16-bit ASNs
There is no flag day
You do NOT need to:
Throw out your old routers
Replace your 16-bit ASN with a 32-bit ASN
87
Conference
88
Compatibility Mode:
Local router only supports 16-bit ASN and remote router uses 32bit ASN
BGP peering initiated:
Remote asks local if 32-bit supported (BGP capability negotiation)
When local says no, remote then presents AS23456
Local needs to be configured to peer with remote using AS23456
Result:
16-bit ASN world sees 16-bit ASNs and 23456 standing in for 32-bit
ASNs
32-bit ASN world sees 16 and 32-bit ASNs
Conference
89
Example:
Internet with 32-bit and
16-bit ASNs
AS-PATH length
maintained
AS 123
AS 70000
AS 80000
170.10.0.0/16
180.10.0.0/16
AS 321
150.10.0.0/16
AS 90000
Conference
180.10.0.0/16
170.10.0.0/16
150.10.0.0/16
90
AS23456 (AS_TRANS)
Conference
91
92
Transition
AS
Conference
93
Conference
94
95
Conference
96
Conference
97
Conference
98
Conference
99
Operation
Add penalty (1000) for each flap
Change in attribute gets penalty of 500
Conference
100
Operation
4000
Penalty
Suppress limit
3000
Penalty
2000
Reuse limit
1000
0
0 1
3 4
5 6 7 8
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Time
Network
Announced
Conference
Network
Not Announced
Network
Re-announced
101
Operation
Only applied to inbound announcements from eBGP
peers
Alternate paths still usable
Controllable by at least:
Half-life
reuse-limit
suppress-limit
maximum suppress time
Conference
102
Configuration
Implementations allow various policy control with flap
damping
Fixed damping, same rate applied to all prefixes
Variable damping, different rates applied to different ranges of
prefixes and prefix lengths
Conference
103
Conference
104
Serious Problems:
"Route Flap Damping Exacerbates Internet Routing
Convergence
Zhuoqing Morley Mao, Ramesh Govindan, George Varghese &
Randy H. Katz, August 2002
Conference
105
Problem 1:
One path flaps:
BGP speakers pick next best path, announce to all peers, flap
counter incremented
Those peers see change in best path, flap counter incremented
After a few hops, peers see multiple changes simply caused by
a single flap prefix is suppressed
Conference
106
Problem 2:
Different BGP implementations have different transit
time for prefixes
Some hold onto prefix for some time before advertising
Others advertise immediately
Conference
107
Solution:
Do NOT use Route Flap Damping whatever you do!
RFD will unnecessarily impair access
to your network and
to the Internet
Conference
108
Conference
109
Conference
110
BGP Communities
Another ISP scaling technique
Prefixes are grouped into different classes or
communities within the ISP network
Each community means a different thing, has a different
result in the ISP network
Conference
111
112
More info at
https://www.sprint.net/index.php?p=policy_bgp
Conference
113
More info at
www.us.ntt.net/about/policy/routing.cfm
Conference
114
Conference
115
ISP Examples:
Verizon Business Europe
aut-num: AS702
descr:
Verizon Business EMEA - Commercial IP service provider in Eur
remarks: VzBi uses the following communities with its customers:
702:80
Set Local Pref 80 within AS702
702:120
Set Local Pref 120 within AS702
702:20
Announce only to VzBi AS'es and VzBi customers
702:30
Keep within Europe, don't announce to other VzBi AS
702:1
Prepend AS702 once at edges of VzBi to Peers
702:2
Prepend AS702 twice at edges of VzBi to Peers
702:3
Prepend AS702 thrice at edges of VzBi to Peers
Advanced communities for customers
702:7020 Do not announce to AS702 peers with a scope of
National but advertise to Global Peers, European
Peers and VzBi customers.
702:7001 Prepend AS702 once at edges of VzBi to AS702
peers with a scope of National.
702:7002 Prepend AS702 twice at edges of VzBi to AS702
peers with a scope of National.
(more)
Conference
116
ISP Examples:
Verizon Business Europe
(more)
mnt-by:
source:
Conference
117
Conference
118
AS5400
BT Ignite European Backbone
Community to
Not announce
Community to
AS prepend 5400
To peer:
5400:2000
5400:1500
5400:1501
5400:1502
5400:1503
5400:1504
5400:1506
5400:2500
5400:2501
5400:2502
5400:2503
5400:2504
5400:2506
All Transits
Sprint Transit (AS1239)
SAVVIS Transit (AS3561)
Level 3 Transit (AS3356)
AT&T Transit (AS7018)
GlobalCrossing Trans(AS3549)
5400:2001
5400:2002
5400:2004
And many
many more!
119
Conference
120
AS3356
Level 3 Communications
------------------------------------------------------customer traffic engineering communities - Suppression
------------------------------------------------------64960:XXX - announce to AS XXX if 65000:0
65000:0
- announce to customers but not to peers
65000:XXX - do not announce at peerings to AS XXX
------------------------------------------------------customer traffic engineering communities - Prepending
------------------------------------------------------65001:0
- prepend once to all peers
65001:XXX - prepend once at peerings to AS XXX
3356:70
3356:80
3356:90
3356:9999
LEVEL3-MNT
RIPE
set local
set local
set local
blackhole
preference to 70
preference to 80
preference to 90
(discard) traffic
And many
many more!
121
Conference
122
Conference
123
Deploying BGP
The role of IGPs and iBGP
Aggregation
Receiving Prefixes
Configuration Tips
Conference
124
Conference
125
Conference
126
eBGP used to
exchange prefixes with other ASes
implement routing policy
Conference
127
eBGP
Conference
eBGP
eBGP
iBGP
iBGP
iBGP
iBGP
IGP
IGP
IGP
IGP
AS1
AS2
AS3
AS4
128
Conference
129
Conference
130
Aggregation
Quality or Quantity?
Conference
131
Aggregation
Aggregation means announcing the address block
received from the RIR to the other ASes connected to
your network
Subprefixes of this aggregate may be:
Used internally in the ISP network
Announced to other ASes to aid with multihoming
Conference
132
Aggregation
Address block should be announced to the Internet as
an aggregate
Subprefixes of address block should NOT be
announced to Internet unless special circumstances
(more later)
Aggregate should be generated internally
Not on the network borders!
Conference
133
Announcing an Aggregate
ISPs who dont and wont aggregate are held in poor
regard by community
Registries publish their minimum allocation size
Anything from a /20 to a /22 depending on RIR
Different sizes for different address blocks
Conference
134
Aggregation Example
100.10.10.0/23
100.10.0.0/24
100.10.4.0/22
customer
Internet
AS100
100.10.10.0/23
Customer has /23 network assigned from AS100s /19 address block
AS100 announces customers individual networks to the Internet
Conference
135
Aggregation Example
100.10.0.0/19
100.10.0.0/19
aggregate
customer
Internet
AS100
100.10.10.0/23
Customer has /23 network assigned from AS100s /19 address block
AS100 announced /19 aggregate to the Internet
Conference
137
Conference
138
Aggregation Summary
Good example is what everyone should do!
Adds to Internet stability
Reduces size of routing table
Reduces routing churn
Improves Internet QoS for everyone
Conference
139
329645
151695
161970
155952
/24s announced
171983
ASes in use
Conference
34696
140
Conference
141
Networks
165
0
0
0
0
3
87
20
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Block
79/8
80/8
81/8
82/8
83/8
84/8
85/8
86/8
87/8
88/8
89/8
90/8
91/8
96/8
97/8
98/8
99/8
112/8
113/8
114/8
115/8
116/8
117/8
Networks
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Block
Networks
Block
Networks
118/8
119/8
120/8
121/8
122/8
123/8
124/8
125/8
126/8
173/8
174/8
186/8
187/8
189/8
190/8
192/8
193/8
194/8
195/8
196/8
198/8
199/8
200/8
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
6275
2390
2932
1338
513
4034
3495
1348
201/8
202/8
203/8
204/8
205/8
206/8
207/8
208/8
209/8
210/8
211/8
212/8
213/8
216/8
217/8
218/8
219/8
220/8
221/8
222/8
0
2276
3622
3792
2584
3127
2723
2817
2574
617
0
717
1
943
0
0
0
0
0
0
142
Conference
Block
Networks
Block
Networks
Block
Networks
Block
Networks
24/8
41/8
58/8
59/8
60/8
61/8
62/8
63/8
64/8
65/8
66/8
67/8
68/8
69/8
70/8
71/8
72/8
73/8
74/8
75/8
76/8
77/8
78/8
3328
3448
1675
1575
888
2890
2418
3114
6601
3966
7782
3771
3221
5280
2008
1327
4050
4
5074
1164
1034
1964
1397
79/8
80/8
81/8
82/8
83/8
84/8
85/8
86/8
87/8
88/8
89/8
90/8
91/8
96/8
97/8
98/8
99/8
112/8
113/8
114/8
115/8
116/8
117/8
1119
2335
1709
1358
1357
1341
2492
780
1466
1068
3168
377
4555
778
725
1312
288
883
890
996
1616
1755
1611
118/8
119/8
120/8
121/8
122/8
123/8
124/8
125/8
126/8
173/8
174/8
186/8
187/8
189/8
190/8
192/8
193/8
194/8
195/8
196/8
198/8
199/8
200/8
1349
1694
531
1756
2687
2400
2259
2514
106
1994
1089
1223
1501
3063
6945
6952
6820
5177
5325
1857
4504
4372
8884
201/8
202/8
203/8
204/8
205/8
206/8
207/8
208/8
209/8
210/8
211/8
212/8
213/8
216/8
217/8
218/8
219/8
220/8
221/8
222/8
4136
11354
11677
5744
3037
3951
4635
6498
5536
4977
3130
3550
3442
7645
3136
1512
1303
2108
980
1058
143
Conference
144
Conference
145
Conference
146
Conference
147
Conference
148
Conference
149
Conference
150
Conference
151
Conference
152
Conference
153
Importance of Aggregation
Size of routing table
Router Memory is not so much of a problem as it was in the
1990s
Routers can be specified to carry 1 million+ prefixes
Conference
154
Conference
155
Conference
156
Aggregation Potential
(source: bgp.potaroo.net/as2.0/)
AS Path
AS Origin
Conference
157
Aggregation
Summary
Aggregation on the Internet could be MUCH better
35% saving on Internet routing table size is quite feasible
Tools are available
Commands on the routers are not hard
CIDR-Report webpage
Conference
158
Receiving Prefixes
Conference
159
Receiving Prefixes
There are three scenarios for receiving prefixes from
other ASNs
Customer talking BGP
Peer talking BGP
Upstream/Transit talking BGP
Conference
160
Receiving Prefixes:
From Customers
ISPs should only accept prefixes which have been
assigned or allocated to their downstream customer
If ISP has assigned address space to its customer, then
the customer IS entitled to announce it back to his ISP
If the ISP has NOT assigned address space to its
customer, then:
Check the five RIR databases to see if this address space really
has been assigned to the customer
The tool: whois
Conference
161
Receiving Prefixes:
From Customers
Example use of whois to check if customer is entitled to announce
address space:
pfs-pc$ whois
inetnum:
netname:
descr:
descr:
descr:
descr:
country:
admin-c:
tech-c:
mnt-by:
changed:
status:
source:
Conference
-h whois.apnic.net 202.12.29.0
202.12.29.0 - 202.12.29.255
APNIC-AP-AU-BNE
APNIC Pty Ltd - Brisbane Offices + Servers
Level 1, 33 Park Rd
PO Box 2131, Milton
Brisbane, QLD.
AU
Portable means its an assignment
to the customer, the customer can
HM20-AP
announce it to you
NO4-AP
APNIC-HM
hm-changed@apnic.net 20030108
ASSIGNED PORTABLE
APNIC
162
Receiving Prefixes:
From Customers
Example use of whois to check if customer is entitled to announce
address space:
$ whois -h whois.ripe.net 193.128.2.0
inetnum:
193.128.2.0 - 193.128.2.15
descr:
Wood Mackenzie
country:
GB
ASSIGNED PA means that it is
admin-c:
DB635-RIPE
Provider Aggregatable address space
tech-c:
DB635-RIPE
and can only be used for connecting
status:
ASSIGNED PA
to the ISP who assigned it
mnt-by:
AS1849-MNT
changed:
davids@uk.uu.net 20020211
source:
RIPE
route:
descr:
origin:
notify:
mnt-by:
changed:
source:
Conference
193.128.0.0/14
PIPEX-BLOCK1
AS1849
routing@uk.uu.net
AS1849-MNT
beny@uk.uu.net 20020321
RIPE
163
Receiving Prefixes:
From Peers
A peer is an ISP with whom you agree to exchange
prefixes you originate into the Internet routing table
Prefixes you accept from a peer are only those they have
indicated they will announce
Prefixes you announce to your peer are only those you have
indicated you will announce
Conference
164
Receiving Prefixes:
From Peers
Agreeing what each will announce to the other:
Exchange of e-mail documentation as part of the peering
agreement, and then ongoing updates
OR
Use of the Internet Routing Registry and configuration tools
such as the IRRToolSet
www.isc.org/sw/IRRToolSet/
Conference
165
Receiving Prefixes:
From Upstream/Transit Provider
Upstream/Transit Provider is an ISP who you pay to
give you transit to the WHOLE Internet
Receiving prefixes from them is not desirable unless
really necessary
special circumstances see later
Conference
166
Receiving Prefixes:
From Upstream/Transit Provider
If necessary to receive prefixes from any provider, care
is required
dont accept RFC1918 etc prefixes
http://www.rfc-editor.org/rfc/rfc5735.txt
dont accept your own prefixes
dont accept default (unless you need it)
dont accept IPv4 prefixes longer than /24
Conference
167
Receiving Prefixes
Paying attention to prefixes received from customers,
peers and transit providers assists with:
The integrity of the local network
The integrity of the Internet
Conference
168
Configuration Tips
Conference
169
Conference
170
iBGP: Next-hop-self
BGP speaker announces external network to iBGP
peers using routers local address (loopback) as nexthop
Used by many ISPs on edge routers
Preferable to carrying DMZ /30 addresses in the IGP
Reduces size of IGP to just core infrastructure
Alternative to using unnumbered interfaces
Helps scale network
Many ISPs consider this best practice
Conference
171
Conference
172
173
ISP
TTL 254
R1
AS 100
R2
TTL 253
Conference
Attacker
TTL 254
174
Conference
175
Templates
Good practice to configure templates for everything
Vendor defaults tend not to be optimal or even very useful for
ISPs
ISPs create their own defaults by using configuration templates
Conference
176
iBGP Template
Example
iBGP between loopbacks!
Next-hop-self
Keep DMZ and external point-to-point out of IGP
Conference
177
iBGP Template
Example continued
Use passwords on iBGP session
Not being paranoid, VERY necessary
Its a secret shared between you and your peer
If arriving packets dont have the correct MD5 hash, they are
ignored
Helps defeat miscreants who wish to attack BGP sessions
Conference
178
eBGP Template
Example
BGP damping
Do NOT use it unless you understand the impact
Do NOT use the vendor defaults without thinking
179
eBGP Template
Example continued
Use maximum-prefix tracking
Router will warn you if there are sudden increases in BGP table
size, bringing down eBGP if desired
Conference
180
Summary
Use configuration templates
Standardise the configuration
Be aware of standard tricks to avoid compromise of
the BGP session
Anything to make your life easier, network less prone to
errors, network more likely to scale
Its all about scaling if your network wont scale, then
it wont be successful
Conference
181
182