![]()
Changes introduced in the 6.0 version:
Changes introduced in the 5.8 version:
Changes introduced in the 5.7 version:
Changes introduced in the 5.6 version:
Changes introduced in the 5.5 version:
Changes introduced in the 5.4 version:
Changes introduced in the 5.3 version:
Changes introduced in the 5.2 version:
Changes introduced in the 5.1 version:
Changes introduced in the 5.0 version:
Changes introduced in the 4.9 version:
Changes introduced in the 4.8 version:
Changes introduced in the 4.7 version:
Changes introduced in the 4.6 version:
Changes introduced in the 4.5 version:
Changes introduced in the 4.4 version:
Changes introduced in the 4.3 version:
Changes introduced in the 4.2 version:
Changes introduced in the 4.1 version:
Changes introduced in the 4.0 version:
Changes introduced in the 3.9 version:
Changes introduced in the 3.8 version:
Changes introduced in the 3.7 version:
Changes introduced in the 3.6 version:
Changes introduced in the 3.5 version:
Changes introduced in the 3.4 version:
Changes introduced in the 3.3 version:
Changes introduced in the 3.2 version:
Changes introduced in the 3.1 version:
Changes introduced in the 3.0 version:
Changes introduced in the 2.9 version:
Changes introduced in the 2.8 version:
173/8 Apr 03 IANA - Reserved 174/8 Apr 03 IANA - Reserved 175/8 Apr 03 IANA - Reserved 176/8 Apr 03 IANA - Reserved 177/8 Apr 03 IANA - Reserved 178/8 Apr 03 IANA - Reserved 179/8 Apr 03 IANA - Reserved 180/8 Apr 03 IANA - Reserved 181/8 Apr 03 IANA - Reserved 182/8 Apr 03 IANA - Reserved 183/8 Apr 03 IANA - Reserved 184/8 Apr 03 IANA - Reserved 185/8 Apr 03 IANA - Reserved 186/8 Apr 03 IANA - Reserved 187/8 Apr 03 IANA - Reserved 189/8 Apr 03 IANA - Reserved 190/8 Apr 03 IANA - Reserved
Changes introduced in the 2.7 version:
Changes introduced in the 2.6 version:
Changes introduced in the 2.5 version:
Changes introduced in the 2.4 version:
Changes introduced in the 2.3 version:
Changes introduced in the 2.2 version:
Changes introduced in the 2.1 version:
Changes on 22 JUN 2001:
Changes on 16 OCT 2001:
Changes on ?? DEC 2001:
BGP is the routing protocal that drives the Internet. Proper configuration of BGP is critical, as mistakes in BGP can result in disaster for both local and remote networks. Further, without a few additional steps to increase the security and defense of BGP, it is possible for miscreants to cause havoc with the BGP and, by extension, routing tables.
This document includes a template configuration for BGP. As with all such templates, this one must be modified to fit the specific requirements of the local network(s). It is not wise to simply cut and paste without a thorough understanding of each command. Comments are included with each command. A more thorough understanding of BGP can be obtained from:
o
Internet Routing Architectures,
by Bassam Halabi, published
by Cisco Press.
o BGP4, by John W. Stewart
III, published by Addison-Wesley.
As an aside, debugging BGP issues can be difficult without an external view. To see how the rest of the Internet views my prefix announcements, I use the route servers. Simply telnet to these route servers and issue commands such as sh ip bgp NETBLOCK or sh ip route NETBLOCK. Here is a partial list:
route-views.oregon-ix.net
ner-routes.bbnplanet.net
route-server.cerf.net
route-server.ip.att.net
route-server.east.attcanada.com
route-server.west.attcanada.com
route-server.cbbtier3.att.net
route-server.gblx.net
route-server.as5388.net
route-server.savvis.net
route-server.colt.net
route-server.opentransit.net
route-server.gt.ca
public-route-server.is.co.za (South African routes only)
route-server.belwue.de
route-views.on.bb.telus.com
route-views.ab.bb.telus.com
route-server.ip.tiscali.net
route-server.wcg.net
route-server.manilaix.net.ph
route-server.ip.ndsoftware.net
route-server.utah.rep.net
route-server.he.net
zebra.swinog.ch
This great collection of route servers, plus a few more, can be found by querying the following range of DNS RRs:
routeserver[1-15].sentex.ca
For example:
dig +short routeserver1.sentex.ca route-views.oregon-ix.net. 198.32.162.100 - or - dig +short routeserver7.sentex.ca route-server.gt.ca. 216.18.63.214
Thanks to Mike Tancsa for making this available!
Thomas Kernen maintains an excellent page of route-servers and more here. Thanks, Thomas! :)
It may also be helpful to receive the bgp-stats report, either daily or weekly. This will help you to size your maximum-prefix statements, as well as maintaining accurate bogon filters. You may subscribe to the bgp-stats report by sending a note to bgp-stats-request@lists.apnic.net with the message text of "subscribe".
While I list the bogon ranges on /8 boundaries, you may prefer a greater level of aggregation. For this I recommend consulting my Bogon List. Don't forget to keep any bogon filters current! You can read more about this at the RIPE NCC De-Bogonising New Addresses page, http://www.ris.ripe.net/debogon/.
Barry Greene and Philip Smith, both of Cisco, have recently released a book entitled Cisco ISP Essentials. This is an excellent collection of clue. You can learn more about it at www.ispbook.com.
Barry also keeps a nice collection of Cisco security documents here.
My thanks to the following folks for providing input and suggestions!
Roy Arends
Larry Bishop
Oded Comay
Piotr Kucharski
Hank Nussbacher
James A. T. Rice
Joshua Sahala
Mike Tancsa
David Wolsefer
Joel Obstfeld
Phillip Smith
Aristidis Lamprianidis
As always, the FIRST community.
Feedback is both welcome and encouraged! This document is a work-in-progress as changes to the Cisco IOS, BGP, or corrections to this document appear. Please send any questions along to noc@cymru.com.
The actual commands are in BOLD text so that they stand out from the comment blocks.
! Our
ASN is 111
router bgp 111
!
! Don't wait for the IGP to catch up.
no synchronization
!
! Be a little more forgiving of an occasional missed keepalive.
no bgp
fast-external-fallover
!
! Track and punt, via syslog, all interesting
observations about our
! neighbors.
bgp
log-neighbor-changes
!
! Set Maximum AS-Path Prepends to 10 to limit an insane number of prepends.
The
Cisco IOS command, which would limit prepends to a
sane level would be :
bgp maxas-limit 10
! (supported
from 12.2, 12.0(17)S, 12.2(33)SRA, 12.2SX and upwards, see
! http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_bgp1.html#wp1013932
! for more details)
! Announce our netblock(s) in a manner that does
not increase CPU
! utilization. Redistributing from an IGP is dangerous as it increases
! the likelihood of flapping and instability. Redistributing static is
! more stable, but requires the CPU to peruse the routing table at a set
! interval to capture any changes. The network statement, combined with
! a null route, is the least expensive (in terms of CPU utilization) and
! most reliable (in terms of stability) option.
network 1.88.0.0 mask
255.255.224.0
!
! Our first neighbor, 10.10.5.1, is an eBGP peer
with the ASN of 333.
neighbor 10.10.5.1 remote-as 333
!
! Set for soft reconfiguration, thus preventing a complete withdrawal
! of all announced prefixes when clear ip bgp x.x.x.x is typed.
neighbor 10.10.5.1
soft-reconfiguration inbound
!
! Type in a description for future reference. Not everyone memorizes
! ASNs. :-)
neighbor 10.10.5.1 description eBGP with ISP333
!
! Set up a password for authentication.
neighbor 10.10.5.1 password
bgpwith333
!
! Hard-set for version 4. Disabled BGP version negotiation, thus
! bringing the peering session on-line more quickly.
neighbor 10.10.5.1 version 4
!
! Block any inbound announcments that include bogon networks. A prefix
! list is used because it is:
! 1) Easier on the CPU than ACLs, and
! 2) Easier to modify.
! See the actual bogons prefix-list below.
neighbor 10.10.5.1 prefix-list bogons in
!
! Announce only those networks we specifically list. This also prevents
! the network from becoming a transit provider. An added bit of protection
! and good netizenship. See the announce
prefix-list below.
neighbor 10.10.5.1 prefix-list
announce out
!
! Prevent a mistake or mishap by our peer (or someone with whom our peer
! has a peering agreement) from causing router meltdown by filling the
! routing and BGP tables. This is a hard limit. At 75% of this limit,
! the IOS will issue log messages warning that the neighbor is approaching
! the limit. All log messages should be sent to a remote syslog host.
! The warning water mark can be modified by placing a value after the
! maximum prefix value, e.g. maximum-prefix 250000 50. This will set the
! IOS to issue warning messages when the neighbor reaches 50% of the
limit.
! Note that this number may need to be adjusted upward in the future to
! account for growth in the Internet routing table.
neighbor 10.10.5.1 maximum-prefix
250000
!
! Our next neighbor is 10.10.10.1, an eBGP peer
with the ASN of 222.
neighbor 10.10.10.1 remote-as 222
neighbor 10.10.10.1 soft-reconfiguration inbound
neighbor 10.10.10.1 description eBGP with
ISP222
neighbor 10.10.10.1 password bgpwith222
neighbor 10.10.10.1 version 4
neighbor 10.10.10.1 prefix-list bogons in
neighbor 10.10.10.1 prefix-list announce out
neighbor 10.10.10.1 maximum-prefix 250000
!
! This is our iBGP peer, 172.17.70.2.
neighbor 172.17.70.2 remote-as 111
!
neighbor 172.17.70.2
soft-reconfiguration inbound
!
! Again, a handy description.
neighbor 172.17.70.2 description iBGP with our other router
!
neighbor 172.17.70.2 password
bgpwith111
! Use the loopback interface for iBGP
announcements. This increases the
! stability of iBGP.
neighbor 172.17.70.2 update-source
Loopback0
neighbor 172.17.70.2 version 4
neighbor 172.17.70.2 next-hop-self
neighbor 172.17.70.2 prefix-list bogons in
neighbor 172.17.70.2 maximum-prefix 250000
!
! Do not automatically summarize our announcements.
no auto-summary
! If we have multiple links on the same router to the same AS, we like
to
! put them to good use. Load balance, per destination, with maximum-paths.
! The limit is six. For our example, we will assume two equal size pipes
! to the same AS.
maximum-paths 2
!
! Now add our null route and the loopback/iBGP
route. Remember to add
! more specific non-null routes so that the packets travel to their
! intended destination!
ip route 1.88.0.0 255.255.224.0 Null0
ip route 1.88.50.0 255.255.255.0 192.168.50.5
ip route 1.88.55.0 255.255.255.0 192.168.50.8
ip route 1.88.75.128 255.255.255.128 192.168.50.10
ip route 172.17.70.2 255.255.255.255 192.168.50.2
!
! We protect TCP port 179 (BGP port) from miscreants by limiting
! access. Allow our peers to connect and log all other attempts.
! Remember to apply this ACL to the interfaces of the router or
! add it to existing ACLs.
! Please note that ACL 185 would block ALL
traffic as written. This
! is designed to focus only on protecting BGP. You MUST modify ACL
! 185 to fit your environment and approved traffic patterns.
access-list 185 permit tcp host 10.10.5.1 host 10.10.5.2 eq
179
access-list 185 permit tcp host 10.10.5.1 eq bgp host 10.10.5.2
access-list 185 permit tcp host 10.10.10.1 host
10.10.10.2 eq 179
access-list 185 permit tcp host 10.10.10.1 eq bgp host 10.10.10.2
access-list 185 permit tcp host 172.17.70.2 host
172.17.70.1 eq 179
access-list 185 permit tcp host 172.17.70.2 eq bgp host 172.17.70.1
access-list 185 deny tcp any any
eq 179 log-input
!
! The announce prefix list prevents us from announcing anything beyond
! our aggregated netblock(s).
ip prefix-list announce description Our
allowed routing announcements
ip prefix-list announce seq
5 permit 1.88.0.0/19
ip prefix-list announce seq
10 deny 0.0.0.0/0 le 32
!
! The bogons prefix list prevents the acceptance
of obviously bogus
! routing updates. This can be modified to fit local requirements.
! While aggregation is possible - certainly desirable - IANA tends
! to allocate netblocks on a /8 boundary. For
this reason, I have
! listed the bogons largely as /8 netblocks. This will make changes
! to the bogons prefix-list easier to accomplish
and less intrusive.
! I have listed more specific netblocks when
documentation, such as
! RFC1918, is more granular.
! Please see the IANA IPv4 netblock assignment
document at the
! following URL:
! http://www.iana.org/assignments/ipv4-address-space
!
! Team Cymru has removed all static
bogon references from this template
! due to
the high probability that the application of these bogon
filters
! will
be a one-time event. Unfortunately many of these templates are
! applied
and never re-visited, despite our dire warnings that bogons
do
! change.
! This
doesn't mean bogon filtering can't be accomplished in
an automated
! manner.
Why not consider peering with our globally distributed bogon
! route-server
project? Alternately you can obtain a current and well
! maintained
bogon feed from our DNS and RADb
services. Read more at the
! link
below to learn how!
! <https://www.team-cymru.org/Services/Bogons/>
Thanks Joel Obstfeld!
Please see the attached documents which contain the required
configurations lines. It's not a 1:1 translation since some of the
commands/functions used
on IOS are enabled by default in IOS-XR.
The order of the
configuration IS important, in that policies need to be
defined before the BGP
process can reference them. If the BGP process is
configured first,
making reference to a policy which hasn't yet been parsed, it will return an
error :
router bgp
<your asn>
address-family ipv4 unicast
!
neighbor x.x.x.x
remote-as 65333
ebgp-multihop 255
description <your description>
update-source Loopback999
password clear <your password>
address-family ipv4 unicast
maximum-prefix 100 90
route-policy drop in
route-policy CYMRUBOGONS out
soft-reconfiguration inbound always
!
!
!
route-policy drop
drop
end-policy
!
route-policy CYMRUBOGONS
if (community matches-every BOGONS) then
set next-hop 192.0.2.1
else
drop
endif
end-policy
!
community-set BOGONS
65333:888
end-set
!
router static
address-family ipv4 unicast
192.0.2.1/32 Null0
!
!
! Template below is based
on recommendations contained in
!
http://www.cymru.com/Documents/secure-bgp-template.html
! Configuration has
been altered for use with IOS XR.
!
! Define prefix-sets
and access-lists that will be used later in
the template
<span prefix-set pfx_announce_permit
! The announce prefix list prevents us from announcing
anything beyond
! our aggregated netblock(s).
#: Our allowed routing announcements
1.88.0.0/19
end-set
!
<span prefix-set pfx_bogons_deny
! The bogons prefix list prevents
the acceptance of obviously bogus
! routing updates. This can be modified to fit local
requirements.
! While aggregation is possible - certainly desirable - IANA
tends
! to allocate netblocks on a /8
boundary. For this reason, have
! listed the bogons largely as /8 netblocks. This will make changes
! to the bogons prefix-list easier
to accomplish and less intrusive.
! Have listed more specific netblocks
when documentation, such as
! RFC1918, is more granular.
! Please see the IANA IPv4 netblock
assignment document at the
! following URL:
! http://www.iana.org/assignments/ipv4-address-space
! Team Cymru has removed all static
bogon references from this template
! due to
the high probability that the application of these bogon
filters
! will
be a one-time event. Unfortunately many of these templates are
! applied
and never re-visited, despite our dire warnings that bogons
do
! change.
! This
doesn't mean bogon filtering can't be accomplished in
an automated
! manner.
Why not consider peering with our globally distributed bogon
! route-server
project? Alternately you can obtain a current and well
! maintained
bogon feed from our DNS and RADb
services. Read more at the
! link
below to learn how!
! <https://www.team-cymru.org/Services/Bogons/>