Deploying Bgp4 (rst-243)
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Deploying Bgp4 (rst-243) as PDF for free.
More details
- Words: 7,779
- Pages: 134
Session Number Presentation_ID
© 2002, Cisco Systems, Inc. All rights reserved.
1
Deploying BGP-4 RST-243
Torsten Neuber [email protected] RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
3
Prerequisites • Understand how BGP scales Internet routing by connecting ISPs with globally unique AS numbers • Understand need for stable BGP advertisement (ie BGP dampening) • Understand difference between BGP external and internal BGP • Basic protocol knowledge: TCP port 179—incremental updates RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
4
Prerequisites • Understand BGP attributes: ASPATH, NEXT_HOP, MED, LOCAL_PREF—allow routing policy via route-map. • Understand the bestpath decision algorithm • Know why to turn off synchronization and auto-summary!
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
5
Overview • Protocol Overview • Using BGP Attributes • Deploying IBGP • Deploying EBGP Connecting to an ISP Being an ISP
• Focus on Stability, Scalability, and Configuration Templates RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
6
Complex Network Scalability
Scalable Stable Simple RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
7
Recap of BGP What Is it? Why Use it?
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
8
Basic to Basics Peering C
A
AS 101
AS 100 D
B
• Runs over TCP—port 179 • Path vector protocol • Incremental updates
E
AS 102
• “Internal” and “External” BGP RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
9
General Operation
• Learns multiple paths via internal and external BGP speakers • Picks THE bestpath, installs it in the IP forwarding table, forwards to EBGP neighbors (not IBGP) • Policies applied by influencing the bestpath selection
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
10
BGP Sessions—TCP Port 179, 4 Basic Message Types
• 1: OPEN MESSAGE Exchange AS, router ID, holdtime Capability negotiation
• 2: NOTIFICATION Example: “peer in wrong AS”
• 3: KEEPALIVE—when no updates • 4: UPDATES (incremental)
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
11
BGP Attributes—Tools for Routing Policy
RST-243
1: ORIGIN
7: AGGREGATOR
2: AS-PATH
8: COMMUNITY
3: NEXT-HOP
9: ORIGINATOR_ID
4: MED
10: CLUSTER_LIST
5: LOCAL_PREF
14: MP_REACH_NLRI
6: ATOMIC_AGGREGATE
15: MP_UNREACH_NLRI
© 2002, Cisco Systems, Inc. All rights reserved.
12
Why Use It?
• You need to scale your IGP • You’re a multihomed ISP customer • You need to transit full Internet routes
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
13
Deploying BGP Turn of the Archaic Features!
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
14
BGP Template - BGP Global Settings router bgp 1 bgp deterministic-med no synchronization no auto-summary distance 200 200 200
For BGP config templates from now on, I’ll assume you’ve already done this!
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
15
Deploying Internal BGP Loopbacks, Peer-Groups, Route Reflectors and Confederations
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
16
Guidelines for Stable IBGP • IBGP peer using loopback addresses neighbor { ip address | peer-group} update-source loopback0 • Independent of physical interface failure • IGP performs any load-sharing • IBGP only—use on RR clients with care!!!
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
17
Peering with Loopbacks Without Loopbacks, the TCP Session Is Always Sourced from the IP Address of the Outbound Interface— Which Can Go Down!
A
B
• Configuration: Router A router bgp 1 neighbor 1.0.1.1 remote-as 1 Router B router bgp 1 neighbor 1.0.1.2 remote-as 1
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
1.0.1.1
1.0.1.2
If Redundant Paths Exist, Use Loopback Interfaces to Establish the Session
18
Guidelines for Scaling IBGP
• Carry only next-hops in IGP • Carry full routes in BGP only if necessary • Do not redistribute BGP into IGP • Use peer groups and RRs
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
19
BGP Template—IBGP Peers IBGP Peer Group AS1 router bgp 1 neighbor internal peer-group neighbor internal description ibgp peers neighbor internal remote-as 1 neighbor internal update-source Loopback0 neighbor internal next-hop-self neighbor internal send-community neighbor internal version 4 neighbor internal password 7 03085A09 neighbor 1.0.0.1 peer-group internal neighbor 1.0.0.2 peer-group internal RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
20
What Is a Peer Group?
• Simplifies configuration • All peer-group members have a common outbound policy • Updates generated once per peer group • Members can have different inbound policy
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
21
Why Route Reflectors? Avoid n(n-1)/2 iBGP Mesh
13 Routers => 78 IBGP Sessions!
n=1000 => Nearly Half a Million iBGP Sessions!
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
22
Using Route Reflectors RR
RRC
Backbone RR
RR
RRC
Cluster A
RRC
RR
RR
Cluster C Golden Rule of RR Loop Avoidance:
Cluster B RRC
“RR Topology Should Follow Physical Topology” => Be Careful with Loopback Peering!!!! RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
RR
Cluster D 23
Route Reflectors • Provide additional control to allow router to advertise (reflect) iBGP learned routes to other iBGP peers Method to reduce the size of the iBGP mesh
• Normal BGP speakers can coexist Only the RR has to support this feature neighbor x.x.x.x route-reflector-client
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
24
Route Reflectors—Terminology Non-client
Route Reflector
Clusters Clients
Clients
Lines Represent Both Physical Links and BGP Logical Connections RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
25
Route Reflectors—Terminology (Cont.) • Route reflector Router that reflects the iBGP information
• Client Routers between which the RR reflects updates (may be fully meshed among themselves)
• Cluster Set of one or more RRs and their clients (may overlap)
• Non-client iBGP neighbour outside the cluster RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
26
What Is a Route Reflector?
• Reflector receives path from clients and non clients • If best path is from a client, reflect to clients and non-clients • If best path is from a non-client, reflect to clients
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
27
Route Reflectors—Hierarchy
• Clusters may be configured hierarchically RRs in a cluster are clients of RRs in a higher level
Level 1
Level 2
Provides a “natural” method to limit routing information sent to lower levels
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
28
Deploying Route Reflectors • Divide backbone into multiple clusters • Each cluster contains at least one RR; Clients can peer with RRs in other clusters for redundancy • RRs are fully meshed via IBGP • Still use single IGP—next-hop unmodified by RR; unless via explicit inbound route-map
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
29
Route Reflectors—Migration • Where to place the route reflectors? Follow the physical topology! This will guarantee that the packet forwarding won’t be affected
• Configure one RR at a time Eliminate redundant iBGP sessions Place one RR per cluster
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
30
Route Reflectors—Migration • Step 0: full iBGP mesh
A
B
E
C
D
Logical Links Physical AND Logical Links RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
31
Route Reflectors—Migration • Step 1: configure D as a RR; E is the client
A
B
E
C
D
RR
Logical Links Physical AND Logical Links RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
32
Route Reflectors—Migration • Step 2: eliminate unnecessary iBGP links
A
B
E
C
D
RR
Logical Links Physical AND Logical Links RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
33
Route Reflectors—Migration • Step 3: repeat for other clusters and iBGP links
A
RR
E
B
C
D
RR
RR
Logical Links Physical AND Logical Links RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
34
BGP Template: Peer-Group for RR Clients router bgp 1 Will this Break the neighbor rr-client peer-group “Golden Rule?” neighbor rr-client description RR clients neighbor rr-client remote-as 1 neighbor rr-client update-source Loopback0 neighbor rr-client route-reflector-client This Line on RRs neighbor rr-client next-hop-self Only RRCs Use Still Use Internal neighbor rr-client send-community Peer Group neighbor rr-client version 4 neighbor rr-client password 7 03085A09 neighbor 10.0.1.1 peer-group rr-client neighbor 10.0.1.2 peer-group rr-client RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
35
RR Specific BGP Attributes RR 1.4.1.1
Router id 1.3.1.1
RRC Router id
A
1.2.1.1
C
• Example: RouterB>sh ip bgp 3.0.0.0 B BGP routing table entry for 3.0.0.0/8 3 1.0.1.2 from 1.4.1.1 (1.1.1.1) Origin IGP, metric 0, localpref 100, valid, internal, best
Router id 1.1.1.1
RRC D
1.0.1.2
Originator: 1.1.1.1 Cluster list: 1.3.1.1, 1.2.1.1
RR
AS3 3.0.0.0
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
36
BGP Attributes: ORIGINATOR_ID • ORIGINATOR_ID Router ID of IBGP speaker that injects route into AS—applied by RR
• Useful for troubleshooting and loop detection
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
37
BGP Attributes: CLUSTER_LIST • CLUSTER_LIST String of CLUSTER_IDs through which the route has passed
• Usually CLUSTER_ID=ROUTER_ID • Overridden by: bgp cluster-id x.x.x.x—but remember: don’t do this!!!! • Useful for troubleshooting and loop detection RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
38
Route Reflectors—Redundancy • Multiple RRs can be configured in the same cluster—but we now advise against this Other RRs in the same cluster should be treated as iBGP peers (non-clients) All RRs in the cluster must have the same cluster-id
• A router may be a client for RRs in different clusters RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
39
Multiple Route Reflectors cluster-id 3.0.0.1 1.0.0.1
RR2 routerB>sh ip bgp 10.0.0.0 BGP routing table entry for 198.10.10.0/24 3 B 2.0.0.2 from 1.0.0.1 (1.0.1.1) Origin IGP, metric 0, localpref 100, valid, internal, best Originator: 1.0.1.1 Cluster list: 3.0.0.1 If A and C have the same CLUSTER_ID, C will not reflect routes from A to B ( ignored due to 3.0.0.1 in the CLUSTER_LIST) ⇒If the direct links C-D and B-A fail, D cannot reach 10.0.0.0 RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
RR1
1.0.1.1
eBGP 2.0.0.2 10.0.0.0/24
Lines Represent Both Physical Links and BGP Logical Connections 40
Route Reflectors—Results • Number of neighbors is reduced No need for full iBGP mesh
• Number of routes propagated is reduced Each RR advertises only the best path to its clients
• Stability and scalability are achieved!
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
41
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
• Usually a single IGP
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
42
Confederations (Cont.) • Visible to outside world as single AS— “Confederation Indentifier” Each sub-AS uses a number from the private space
• iBGP speakers in sub-AS are fully meshed The total number of neighbors is reduced by limiting the full mesh requirement to only the peers in the sub-AS
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
43
Confederations (Cont.) Sub-AS 65530 AS 2
B Sub-AS 65532
Sub-AS 65531
• Configuration (rtr B): router bgp 65532 confederation identifier 2 bgp confederation peers 65530 65531 neighbor 141.153.12.1 remote-as 65530 neighbor 141.153.17.2 remote-as 65531 RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
44
Route Propagation Decisions • Same as with “normal” BGP: From peer in same sub-AS → only to external peers From external peers → to all neighbors
• “External peers” refers to Peers outside the confederation Peers in a different sub-AS Preserve LOCAL_PREF, MED and NEXT_HOP RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
45
Confederations (Cont.) • Example (cont.): BGP table version is 78, local router ID is 141.153.17.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete
RST-243
Network
Next Hop
*> 10.0.0.0
141.153.14.3
0
100
0
(65531) 1 i
*> 141.153.0.0 141.153.30.2
0
100
0
(65530) i
*> 144.10.0.0
141.153.12.1
0
100
0
(65530) i
*> 199.10.10.0 141.153.29.2
0
100
0
(65530) 1 i
© 2002, Cisco Systems, Inc. All rights reserved.
Metric LocPrf Weight Path
46
RRs or Confederations
Internet Connectivity
Multi-Level Hierarchy
Policy Control
Scalability
Migration Complexity
Confederations
Anywhere In the Network
Yes
Yes
Medium
Medium To High
Route Reflectors
Anywhere In the Network
Yes
Yes
Very High
Very Low
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
47
More Points about Confeds • Can ease “absorbing” other ISPs into you ISP—eg, if one ISP buys another (can use local-as feature to do a similar thing) • You can use route-reflectors within confederation sub-as to reduce the sub-as ibgp mesh
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
48
So Far… • Is IBGP peering Stable? Use loopbacks for peering
• Will it Scale? Use peer groups Use route reflectors
• Simple, hierarchical config?
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
49
COMMUNITIES They’re for Everyone!
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
50
Problem: Scale Routing Policy Solution: COMMUNITY • NOT in decision algorithm • BGP route can be a member of many communities • Typical communities: Destinations learned from customers Destinations learned from ISPs or peers Destinations in VPN—BGP community is fundamental to the operation of BGP VPNs RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
51
Problem: Scale Routing Policy Solution: COMMUNITY Communities: 1:100—Customer Routes 1:80— ISP Routes
ISP 2
ISP 1
ISP 4
ISP 3 0.0.0.0
Customer 1 (no Default, Wants Full Routes) RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
Customer 2 (Uses Default, Wants Your Routes) 52
Problem: Scale Routing Policy Solution: COMMUNITY Communities: 1:100—Customer Routes 1:80— ISP Routes
Set Community 1:80
ISP 1 Match Community 1:100 1:80
ISP 3
Match Community 1:100
Match Community 1:100
Set Community 1:100
Customer 1 (no Default, Wants Full Routes) RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
ISP 2
ISP 4 0.0.0.0
Customer 2 (Uses Default, Wants Your Routes) 53
BGP Attributes: COMMUNITY
• Activated per neighbor/peer-group: neighbor {peer-address | peer-group-name} send-community
• Carried across AS boundaries • Common convention is string of four bytes::[0-65536]
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
54
BGP Attributes: COMMUNITY (Cont.) • Each destination can be a member of multiple communities • Using a route-map: set community <1-4294967295> community number
RST-243
aa:nn
community number in aa:nn format
additive
Add to the existing community
none
No community attribute
local-AS community)
Do not send to EBGP peers (well-known
no-advertise community)
Do not advertise to any peer (well-known
no-export community)
Do not export outside AS/confed (well-known
© 2002, Cisco Systems, Inc. All rights reserved.
55
Community Filters • Filter based on Community Strings ip community-list <1-99> [permit|deny] comm ip community-list <100-199> [permit|deny] regexp
• Per neighbor Inbound or outbound route-maps match community [exact-match] exact match only for standard lists
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
56
Community Filters • Example 1: Mark some prefixes as part of the 1:120 community (+remove existing community!)
• Configuration: router bgp 1 neighbor 10.0.0.1 remote-as 2 neighbor 10.0.0.1 send-community neighbor 10.0.0.1 route-map set_community out ! route-map set_community 10 permit match ip address 1 set community 1:120 ! access-list 1 permit 10.10.0.0 0.0.255.255 RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
57
Community Filters • Example 2: Set LOCAL_PREF depending on the community that the prefix belongs to.
• Configuration: router bgp 1 neighbor 10.0.0.1 remote-as 2 neighbor 10.0.0.1 route-map filter_on_community in ! route-map filter_on_community 10 permit match community 1 set local-preference 150 ! ip community-list 1 permit 2:150 RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
58
Regular Expression Syntax—URL • Overview of IOS regular expression syntax: http://www.cisco.com/univercd/cc/td/doc/prod uct/software/ios11/arbook/arapptrn.htm
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
59
Deploying External BGP for Enterprises Aggregation, Policy, and Loadsharing
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
60
Tasks • Steps Configure neighbor Advertise stable prefixes to your ISP Set inbound policy Set output policy Configure loadsharing/multi-homing
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
61
BGP Template: BGP to an ISP AS 2
Router B: router bgp 1 10.0.0.0 network 10.60.0.0 mask 255.255.0.0 .1 A neighbor external peer-group neighbor external remote-as 2 AS 1 Is a Customer neighbor external description ISP connection of ISP AS 2 neighbor external remove-private-AS neighbor external version 4 10.200.0.0 neighbor external prefix-list ispout out ; “accident” filter neighbor external route-map ispout out ; “real” filter neighbor external route-map ispin in .2 B neighbor external password 7 020A0559 10.60.0.0/16 neighbor external maximum-prefix 65000 [warning-only] AS1 neighbor 10.200.0.1 peer-group external ip route 10.60.0.0 255.255.0.0 null0 254 RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
62
Neighbor Template: Notes The slide shows a “complete” EBGP configuration. Notice that it has quite a few more features enabled than the simple configuration I gave at the start of the session. These features are not all mandatory—they are suggestions, and you should read the justifications that follow to see if they make sense in your network. I begin my generating a stable aggregate (or supernet) route that covers all of the subnets in my network. There is no need for the Internet to know about more specific routes in my network, and I do not want to “flap” routes as these individual subnets may come and go within my network. First, even though there is only one neighbor, I define a peer group. This does no harm, and may remind me to re-use the peer-group if I have a another session to the same ISP (with the same outbound policy), thereby obtaining the update generation efficiency that comes with this feature. Next, I define the remote-as 2, and the provide a text description. I also instruct the neighbor to remove any private AS numbers (64512-65535). Although not strictly necessary if you are not using private AS, this is a nice safeguard should you ever decide to use private AS numbers in your network, and forget to update your outbound policy accordingly. I lock down the BGP version to version 4, to guard against the hopefully rare, but possible, outcome the ISP configures their sessions with version 3 (call me paranoid :-) ). RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
63
Neighbor Template: BGP to an ISP Now I apply the routing policy. Because I’m paranoid, I double-up on the outbound policy. I apply a route-map containing a community list as my “primary” filter; however I back this up with a prefix list. This is only really feasible if you are an enterprise and the number of entries in the prefix-list is small. For an ISP, you will probably just use a community list, and extreme care!!! I apply an inbound policy, which essentially prevents me against mistakes my ISP make make, such as sending me my own routes, sending me private IP address space (eg network 10.0.0.0 etc). Speaking of mistakes: what if the ISP messes up their outbound policy and sends me more routes than the memory in my router can take? If this router is not only connecting me to the outside world, but also performing critical routing functions WITHIN my network, it would be bad for a problem with the ISP to disrupt internal network connectivity. I protect my router against this by using the “maximumprefix” command. I know roughly how many routes my ISP should be sending me, and I choose a number a little higher than this—if the ISP sends me more, then the router will close down the session, and keep it down until I issue a “clear ip bgp 10.200.0.1”. Alternatively, if I know that network management is quick to respond to problems, I could just configure the command to log a warning instead. Finally, I apply a password, negotiated with my ISP, to the session. RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
64
Maximum Prefix Tracking (Cont.) • Sample logs: The number of prefixes received from a peer reaches 75% of the maximum configured: %BGP-4-MAXPFX: No. of prefix received from 44.1.1.2 reaches 3, max 4 The number of prefix exceeds the maximum number of prefixes configured: %BGP-3-MAXPFXEXCEED: No. of prefix received from 44.1.1.2: 4 exceed limit 3
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
65
Tasks • Steps Configure neighbor Advertise stable prefixes to your ISP Set inbound policy Set output policy Configure loadsharing/multi-homing
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
66
Advertise Stable Prefixes to Your ISP
• Avoid redistribution—it propagates IGP instabilities to the Internet; Unstable routes may be dampened! • Try to summarize! • For loadsharing, may split the aggregate—more later
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
67
BGP Template: BGP to an ISP The first instinct for many people is to redistribute their IGP into BGP. This is a bad idea for a couple of reasons: First, IGPs tend to have a lot our routing activity as they route-around network failures. This is the good an dproper behavior of an IGP. However, one of primary goals of BGP is to hide “internal” rouring changes to your network that have no impact on global routing. Remember it is common practice by ISPs in the Internet to “dampen” unstable routes learned from the customers of other ISPs. Second, the subnetting used by an IGP is probably not of interest to the wider Internet. As with good IGP design, you should attempt to “summarize” you routes, so that you advertise the minimum number of routes to the Internet routing tables. It’s everyone’s responsibility to try and minimize the size of the Internet routing tables. You can also use a route-map to adjust other BGP attributes. For example, you may connect to your ISPs in two location, and generate two aggregates. You can set the MEDs so that traffic for one aggregate will come into one link, and traffic to the other will come in the other link (with both links providing a backup to the other). Now I apply the routing policy. RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
68
Why Summarize?
• Reduce number of Internet prefixes • Increase stability—aggregate stays even if specifics come and go
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
69
How to Summarize? • Use the “network” statement to define prefix—can add route-map • network statement only installs BGP route if there is a matching route in IGP => lock down a stable static to null0; set admin distance to 254 so it does not override any “real” IGP route router bgp 1 network 10.60.0.0 mask 255.255.0.0 : ip route 10.60.1.0 255.255.255.0 null0 254 RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
70
Tasks • Steps Configure neighbor Advertise stable prefixes to your ISP Set inbound policy Set output policy Configure loadsharing/multi-homing
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
71
Why Inbound Policy?
• Apply a recognizable community to use in outbound filters or other policy • Apply local preferences • Filter our you own/martian routes • Multihoming loadsharing—more later
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
72
BGP Template—Inbound Policy
route-map ISPin permit deny 10 match ip address prefix-list ISPout sanity-check route-map ISPin permit 20 set local-preference 200 routes from ISP—you could use the“no-export” well set community 1:2 known community instead
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
73
Notes on Inbound Policy Template Now let’s look at inbound policy. The roles of inbound policy are to protect you against mistakes made by your ISP; to place routes into communities for subsequent use in outbound policy; and to modify BGP attributes to allow us to control which exit we use to send traffic to various destinations on the Internet. To implement inbound policy I apply a route-map to the peer-group. Remember than inbound-policy does NOT have to be the same for all peer-group members, so I can apply different policies to different neighbors within a peer-group. The route-map, which I’ve call ISPin does three things: 1) rejects any networks in prefix-list ISPout—this prefix lists contains the prefixes I send to my ISP, so I should not expect to receive them back. I also call a prefix list that rejects private address space and other “insane” or “martian” (not on this planet!) routes. 2) applied a local-preference of 200 to all of the routes—perhaps because this exist point is the primary exit point, and another connection to my ISP is the backup, and uses the default local-preference of 100. 3) Put the routes in community 1:2, which signifies “routes I’ve learned from my ISP”. RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
74
Sanity-Check Prefix-List 1/2 ip prefix-list sanity-check seq 5 deny 0.0.0.0/32 # deny the default route - YOU MAY WANT TO OMIT THIS LINE ip prefix-list sanity-check seq 10 deny 0.0.0.0/8 le 32 # deny anything beginning with 0 ip prefix-list sanity-check seq 15 deny 0.0.0.0/1 ge 20 # deny masks > 20 for all class A nets (1-127) ip prefix-list sanity-check seq 20 deny 10.0.0.0/8 le 32 # deny 10/8 per RFC1918 ip prefix-list sanity-check seq 25 deny 127.0.0.0/8 le 32 # reserved by IANA - loopback address ip prefix-list sanity-check seq 30 deny 128.0.0.0/2 ge 17 deny masks >= 17 for all class B nets (129-191) ip prefix-list sanity-check seq 35 deny 128.0.0.0/16 le 32 # deny net 128.0 - reserved by IANA ip prefix-list sanity-check seq 40 deny 172.16.0.0/12 le 32 # deny 172.16 as RFC1918 RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
75
Sanity-Check Prefix-List 2/2 ip prefix-list sanity-check seq 45 deny 192.0.2.0/24 le 32 # class C 192.0.20.0 reserved by IANA ip prefix-list sanity-check seq 50 deny 192.0.0.0/24 le 32 # class C 192.0.0.0 reserved by IANA ip prefix-list sanity-check seq 55 deny 192.168.0.0/16 le 32 # deny 192.168/16 per RFC1918 ip prefix-list sanity-check seq 60 deny 191.255.0.0/16 le 32 # deny 191.255.0.0 - IANA reserved (I think) ip prefix-list sanity-check seq 65 deny 192.0.0.0/3 ge 25 # deny masks > 25 for class C (192-222) ip prefix-list sanity-check seq 70 deny 223.255.255.0/24 le 32 # deny anything in net 223 - IANA reserved ip prefix-list sanity-check seq 75 deny 224.0.0.0/3 le 32 # deny class D/Experimental RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
76
Tasks • Steps Configure neighbor Advertise stable prefixes to your ISP Set inbound policy Set output policy Configure loadsharing/multi-homing
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
77
Why Outbound Policy? • Main filter based on communities • Adding a prefix filter helps protect against mistakes (can apply as-path filters too) • Send community based on agreements with ISP—eg RFC1998 (remember to config send-community) • Multihoming loadsharing policy
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
78
Notes On Outbound Policy Now that inbound policy is set, I next setup the outbound policy. A common mistake made by many enterprises that dual home it to take a full set of routes from one ISP, and immediately send them up to the other ISP. This effectively says the entire Internet is reachable through your network!!! Outbound policy prevents this from occurring, so you can see why it’s critical. I typically use primary outbound filter based on communities. I only send to my ISP all of the routes originated in my network, which I identify with the community 1:1. In smaller installations, where the number of prefixes in the network is small, I may also use a prefix-list as a “backup” for the primary community filter. This does nothing more than to help protect the world against my mistakes!!! :-) I may also have configured some communities in agreement with my ISP. For example, RFC1998 describes a way to indicate which of your ISPs is primary a secondary for a particular set of routes. Finally, you can configure any multihoming/loadsharing policy. You may want to divide your address space, and make traffic to half of your network come in via one ISP, and traffic for the other half come in through the other.
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
79
BGP Template—Outbound Policy
ip prefix-list ISPout seq 5 permit 10.60.0.0 255.255.0.0 : ip community-list 1 permit 1:1 ; all routes to send to ISP : route-map ISPout permit 10 match community 1 ; Internet transit community set community 1:3 [additive] ; something agreed with ISP
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
80
Notes On Outbound Policy
The previous slide shows my outbound policy. First, the prefix-list ISPout matches all of the routes I intend to send to the Internet—in this case only one—life is simple in the powerpoint world of network design :-) This prefix-list is my “backup” in case I make a mistake with communities. I only used it on my connections to my ISP. The primary filter is based on communities. I match all communities in communitylist 1: ie, only community 1:1, corresponding to all the routes local to my network. This assumes that on ingress to by BGP tables (either via EBGP sessions, “network/aggregate-address”, or redistribution from an IGP, I have used a routemap to set the community to 1:1. Finally I add the outbound community to 1:3 community attribute. This is done to meet some arbitrary agreement I’ve have made with my ISP on how it will treat routes I put in this community.
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
81
Tasks • Steps Configure neighbor Advertise stable prefixes to your ISP Set inbound policy Set output policy Configure loadsharing/multi-homing
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
82
Load-Sharing Template: Single Path Router A: interface loopback 0 ip address 1.0.0.1 255.255.255.255 ip route 2.0.0.1 255.255.255.255 serial0/0 ip route 2.0.0.1 255.255.255.255 serial0/1 ! router bgp 1 neighbor 2.0.0.1 remote-as 2 neighbor 2.0.0.1 update-source loopback0 neighbor 2.0.0.1 ebgp-multi-hop 2
A AS1 RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
B AS2
Loopback 0 2.0.0.1
83
Load-Sharing Template: Multiple Paths from Same AS Router A: router bgp 1 neighbor 2.0.0.1 remote-as 2 neighbor 2.0.0.2 remote-as 2 maximum-paths 2 ; can configure up to 6
B A AS 1
2.0.0.1
AS 2 C
2.0.0.2
• Outbound loadsharing works well :-) • Inbound loadsharing depends on ISP IGP :-| RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
84
What Is Multi-homing?
• Connecting to two or more ISPs to increase: Reliability—one ISP fails, still OK Performance—better paths to common Internet destinations
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
85
Types of Multi-homing
• Three common cases: Default from all ISPs Default + customer routes from all ISPs Full routes from all ISPs
• Look first at outbound loadsharing
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
86
Default from All ISPs
• Low memory/CPU solution • All ISPs send (or you generate) default • ISP decided by IGP metrics to reach default
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
87
Default from All ISPs Customer AS 4 4.0.0.0/8
ISP
ISP
AS 2
AS 3 D
E 0.0.0.0
0.0.0.0 A
B
AS 1 C RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
C Chooses Lowest IGP Metric to Default 88
Customer+Default from All ISPs
• Medium memory and CPU • “Best” path—usually shortest AS-path • Use local-preference to override based on prefix, as-path, or community • IGP metric to default used to reach nondirect customers of ISPs
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
89
Customer Routers from All ISPs Customer AS 4 4.0.0.0/8
ISP
ISP
AS 2
AS 3 D
C Chooses Shortest AS Path
E A
AS 1
B
C RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
90
Customer Routes from All ISPs Customer AS 4 4.0.0.0/8
ISP
ISP AS 2
AS 3 800
D
C Chooses Highest Local-Preference
A
AS 1 C
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
B
E
ip prefix-list AS4 permit 4.0.0.0/8 route-map AS3in permit 10 match ip address prefix-list AS4 set local-preference 800 91
Customer Routes from All ISPs Tier 1 ISP
Tier 1 ISP
AS 4
AS 5
Tier 2 ISP
Tier 1 ISP
AS 2
AS3 D
E
A AS400 Takes SubOptimal AS Path RST-243
AS 6
© 2002, Cisco Systems, Inc. All rights reserved.
AS 1
B
C 92
Full Routes from All ISPs
• Higher memory/CPU solution • Reach all destinations by “best” path—usually shortest AS path • Can still manually tune using local-pref and as-path/community/prefix matches
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
93
Full Routes from All ISPs Tier 1 ISP
Tier 1 ISP
AS 4
AS 5
Tier 2 ISP
Tier 1 ISP
AS 2
AS3 D
E
A C Chooses Shortest AS Path RST-243
AS 6
© 2002, Cisco Systems, Inc. All rights reserved.
AS 1
B
C 94
Controlling Inbound Traffic?
• Inbound is more difficult to control due to lack of a transitive metric • You can evenly divide outgoing address blocks across providers, but what happens to redundancy? • If you split your address block, ISPs may filter out the specifics anyway
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
95
Controlling Inbound Traffic? (Cont.) • Bad Internet citizen: Divide address space Set as-path prepend
• Good Internet citizen—RFC2260 Divide address space Use “advertise maps”
• Results may not be as good as NAT with transport level loadsharing Warning: if you split your address block using these techniques it may be filtered by some ISPs RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
96
Using AS-PATH Prepend Customer AS 100
to 10.1/16
10.1.0.0/16 3 1 1 10.1.0.0/16 2 1 (best) 10.2.0.0/16 3 1 (best) 10.2.0.0/16 2 1 1
ISP
ISP AS 2
AS 3 E
D A
B
AS 1 10.1/16
RST-243
C
10.2/16
© 2002, Cisco Systems, Inc. All rights reserved.
30.0.0.1
router bgp 1 neighbor 30.0.0.1 remote-as 3 neighbor 30.0.0.1 route-map AS3out out ip prefix-list AS1 permit 10.1.0.0/16 route-map AS3out permit 10 match ip address prefix-list AS1 set as-path prepend 1 97
Using an Advertise-Map router bgp 100 neighbor advertise-map am non-exist-map bb access-list 1 permit 10.15.7.0 !Advertise when... 1.10/16 10.15.7/24 Auto-Inject access-list 2 permit 10.15.0.0 !… this disappears route-map am permit 10 match ip address 1 10.15/16 route-map bb permit ISP1 match ip address 2 ISP2 R1 R3
1.10.6/24
10.15.7/24 R2
10.15.20/30 R4
AS 2
10.15.7/24
1.10.6/24 1.10.6.1
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
10.15.7.4 98
Summary for Enterprise EBGP • Stability through: Aggregation/summary routes Multihoming Inbound/outbound policy
• Scalability of memory/CPU: Default, customer routes, full routes
• Simplicity using “standard” solutions
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
99
Deploying External BGP for ISPs Route Aggregation, Customer Aggregation, NAPs
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
100
ISP EBGP Tasks
• Configure stable aggregates • Scale BGP customer aggregation • Offer a choice of route-feeds • Peer with other providers • Provide a backup service
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
101
What Is Aggregation? • Summarization based on specifics from the BGP routing table 10.60.1.0 255.255.255.0 10.60.2.0 255.255.255.240 => 10.60.0.0 255.255.0.0
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
102
How to Aggregate • aggregate-address 10.60.0.0 255.255.0.0 {as-set} {summary-only} {route-map} • Use as-set to include path and community info from specifics • summary-only suppresses specifics • route-map sets other attributes
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
103
How to Aggregate—Notes So what is aggregation? Aggregation is generating that all-important stable route that summarizes all of the routes I want to send to the Internet. My route is stable because it is common practice by ISPs in the Internet to “dampen” the routes learned from the customers of other ISPs. Generating a stable aggregating it a three step process. First I configure the “aggregate-address” command to define the aggregate prefix to be generated. The command includes both net and mask. If I include the “as-set” keyword, it causes the router to generate an AS-SET within the AS-PATH. Remember from earlier in the session, that an AS-SET includes ASPATH information from all more specific routes that contributed to the aggregate. As well as generating an AS-SET, the router will also include BGP community information from all of the more specific routes in the community attribute of the aggregate route. By default, the aggregate address command does NOT filter out the more specific BGP routes. TO do this you need to add the “summary-address” keyword. Mostly likely you will want to do this. You can also use a route-map to adjust other BGP attributes. For example, you may connect to your ISPs in two location, and generate two aggregate. You can set the MEDs so that traffic for one aggregate will come into one link, and traffic to the other will come in the other link (with both links providing a backup to the other). RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
104
Why Aggregate? • Reduce number of Internet prefixes— advertise only your CIDR block • Increase stability—aggregate stays even if specifics come and go • Stable aggregate generation: router bgp 1 aggregate-address 10.60.0.0 255.255.0.0 as-set summary-only network 10.60.1.0 255.255.255.0 : ip route 10.60.1.0 255.255.255.0 null0 254 RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
105
Why Aggregate: Notes Once you’ve configured the aggregate, the next step is to configure a stable MORE SPECIFIC route in the BGP table. After all, your aggregate depends on the existing of more specific routes, to you must ensure at least one of the more specific routes is stable. To do this, use the “network” command. Choose a more specific route than your aggregate—a route that is used somewhere in route network. In the slide I’ve chosen 10.60.1/24. The network command will install a corresponding route in the BGP table, ONLY if there is a matching route in the IP routing table. The third, and final step, is therefore to generate a stable route in the IP routing table. To do this, I configure a STATIC route for 10.60.1/24, pointing to the NULL0 interface. However, I do not want this route to override any “real” route that I’m learning via an IGP for 10.60.1/24—so, I set the ADMIN DISTANCE of the static route to 254. Note that if you do note want to generate AS-SET/community summary information, you can omit the aggregate-address command. Use the network command to generate the aggregate prefix, and then put a matching static route in pointing to NULL0. Many, perhaps most, folks tend to do it this way, and do not use the aggregate address command. Note that you need to be careful to filter out more specific BGP routes if you use this technique, as the network command does not provide any “summary-only” functionality. RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
106
BGP Attributes Atomic Aggregate
• Indicates loss of AS-PATH information • Must not be removed once set • Set by: aggregate-address x.x.x.x • Not set if as-set keyword is used, however, AS-SET and COMMUNITY then carries information about specifics
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
107
BGP Attributes: Aggregator
• AS number and IP address of router generating aggregate • Useful for troubleshooting • Only set by aggregate-address; NOT set by the network statement
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
108
Aggregate Attributes
NEXT_HOP = local (0.0.0.0) WEIGHT = 32768 LOCAL_PREF = none (assume 100) AS_PATH = AS_SET or nothing ORIGIN = IGP MED = none
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
109
ISP EBGP Tasks • Configure stable aggregates • Scale BGP customer aggregation • Offer a choice of route-feeds • Peer with other providers • Provide a backup service • Propagate QoS policy
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
110
Customer Aggregation Guidelines • Define at least three peer groups: cust-default—send default route only cust-cust—send customer routes only cust-full —send full Internet routes
• Identify routes via communities eg, 2:100=customers; 2:80=peers
• Apply passwords and an inbound prefixlist on a per neighbor basis RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
111
Customer Aggregation Your AS CIDR Block: 10.0.0.0/8
CORE Route Reflector
Aggregation Router (RR Client)
Full Routes “Default” Peer Group Peer Group
Client Peer Group
Customer Routes Peer Group
Apply Passwords and Inbound Prefix-list Directly to Each Neighbor RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
112
BGP template - customers neighbor x.x.x.x remote-as X neighbor x.x.x.x peer-group (cust-full or cust_cust or cust_default) neighbor x.x.x.x password <password> neighbor x.x.x.x prefix-list ASXXX in . ip prefix-list ASXXX seq 5 permit <prefix>
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
113
BGP template - full routes peer-group neighbor cust-full peer-group neighbor cust-full description Send full Routes neighbor cust-full remove-private-AS neighbor cust-full version 4 neighbor cust-full route-map cust-in in neighbor cust-full route-map full-routes out .
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
114
BGP template: full routes route-map ip prefix-list cidr-block seq 5 deny 10.0.0.0/8 ge 9 ip prefix-list cidr-block seq 10 permit 0.0.0.0/0 le 32 ip community-list 1 permit 2:100 ip community-list 80 permit 2:80 . route-map full-routes permit 10 match ip cidr-block
; deny CIDR subnets
match community 1 80
; customer & peers
set metric-type internal
; MED = IGP metric
set ip next-hop peer-address ; our own RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
115
BGP template: customer inbound route-map
route-map cust-in permit 10 set metric 4294967294 ; ignore MED set ip next-hop peer-address set community 2:100
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
116
BGP template: customer routes peer-group neighbor cust-cust peer-group neighbor cust-cust description customer routes neighbor cust-cust remove-private-AS neighbor cust-cust version 4 neighbor cust-cust route-map cust-in in neighbor cust-cust route-map cust-routes out
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
117
BGP Template: template: customer routes route-map
route-map cust-routes permit 10 match ip cidr-block match community 1 ; customers only set metric-type internal ; MED = igp metric set ip next-hop peer-address ; our own
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
118
BGP Template: default route peer-group neighbor cust-default peer-group neighbor cust-default description Send default neighbor cust-default default-originate route-map default-route neighbor cust-default remove-private-AS neighbor cust-default version 4 neighbor cust-default route-map cust-in in neighbor cust-default prefix-list deny-all out ip prefix-list deny-all seq 5 deny 0.0.0.0/0 le 32
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
119
ISP EBGP Tasks
• Configure stable aggregates • Scale BGP customer aggregation • Offer a choice of route-feeds • Peer with other providers
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
120
Peering with other ISPs
• Similar to EBGP customer aggregation except inbound prefix filtering is rarely used (lack of global registry) • Use maximum-prefix and prefix sanity checking instead • Still use per-neighbor passwords!
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
121
BGP Template: ISP peers peer-group neighbor nap peer-group neighbor nap description for peer ISPs neighbor nap remove-private-AS neighbor nap version 4 neighbor nap prefix-list sanity-check in neighbor nap prefix-list cidr-block out neighbor nap route-map nap-out out neighbor nap maximum prefix 30000
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
122
BGP Template: ISP peers route-
route-map nap-out permit 10 match community 1 ; customers only set metric-type internal ; MED = IGP metric set ip next-hop peer-address ; our own
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
123
Peer Groups for NAPs: Sanity-Check Prefix-List # FIRST - FILTER OUT YOUR IGP ADDRESS SPACE!! ip prefix-list sanity-check seq 5 deny 0.0.0.0/32 # deny the default route ip prefix-list sanity-check seq 10 deny 0.0.0.0/8 le 32 # deny anything beginning with 0 ip prefix-list sanity-check seq 15 deny 0.0.0.0/1 ge 20 # deny masks > 20 for all class A nets (1-127) ip prefix-list sanity-check seq 20 deny 10.0.0.0/8 le 32 # deny 10/8 per RFC1918 ip prefix-list sanity-check seq 25 deny 127.0.0.0/8 le 32 # reserved by IANA - loopback address ip prefix-list sanity-check seq 30 deny 128.0.0.0/2 ge 17 deny masks >= 17 for all class B nets (129-191) ip prefix-list sanity-check seq 35 deny 128.0.0.0/16 le 32 # deny net 128.0 - reserved by IANA ip prefix-list sanity-check seq 40 deny 172.16.0.0/12 le 32 # deny 172.16 as RFC1918 RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
124
Peer Groups for NAPs: Sanity-Check Prefix-List ip prefix-list sanity-check seq 45 deny 192.0.2.0/24 le 32 # class C 192.0.20.0 reserved by IANA ip prefix-list sanity-check seq 50 deny 192.0.0.0/24 le 32 # class C 192.0.0.0 reserved by IANA ip prefix-list sanity-check seq 55 deny 192.168.0.0/16 le 32 # deny 192.168/16 per RFC1918 ip prefix-list sanity-check seq 60 deny 191.255.0.0/16 le 32 # deny 191.255.0.0 - IANA reserved (I think) ip prefix-list sanity-check seq 65 deny 192.0.0.0/3 ge 25 # deny masks > 25 for class C (192-222) ip prefix-list sanity-check seq 70 deny 223.255.255.0/24 le 32 # deny anything in net 223 - IANA reserved ip prefix-list sanity-check seq 75 deny 224.0.0.0/3 le 32 # deny class D/Experimental RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
125
Summary for Deploying EBGP • Stability through: Aggregation/summary routes Inbound prefix-filtering and passwords Apply “sanity-check” and maximum-prefix feature to ISP peering
• Scalability of memory/CPU: Three peer-groups for customers: Default, customer routes, full routes One peer group for ISP peers
• Simplicity using “standard” solutions RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
126
Session Summary 1 • Scalability: Use attributes, especially community Use peer groups and route reflectors
• Stability: Use loopback addresses for IBGP Generate aggregates/summary addresses Apply passwords Always filter inbound and outbound
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
127
Session Summary 2 • Simplicity—standard solutions: Three multihoming options Group customers into communities Apply standard policy at the edge Avoid “special configs” Script your config generation
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
128
For Further Reference: • BGP bestpath http://www.cisco.com/warp/public/459/25.shtml
• Case studies on www.cisco.com: http://www.cisco.com/warp/public/459/18.html
• www.cisco.com—search “BGP” • www.nanog.org
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
129
Recommended Reading Cisco BGP-4 Command and Configuration Handbook ISBN: 1-58705-017-X Advanced IP Network Design ISBN: 1-57870-097-3 Internet Routing Architectures ISBN: 1-57870-233-X Routing TCP/IP, Volume II ISBN: 1-57870-089-2 Troubleshooting IP Routing Protocols ISBN: 1-58705-019-6 Available online or on-site at the Cisco Company Store RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
130
Deploying BGP-4 RST-243
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
131
Please Complete Your Evaluation Form RST-243
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
132
Session Number Presentation_ID
© 2002, Cisco Systems, Inc. All rights reserved.
133
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
134
© 2002, Cisco Systems, Inc. All rights reserved.
1
Deploying BGP-4 RST-243
Torsten Neuber [email protected] RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
3
Prerequisites • Understand how BGP scales Internet routing by connecting ISPs with globally unique AS numbers • Understand need for stable BGP advertisement (ie BGP dampening) • Understand difference between BGP external and internal BGP • Basic protocol knowledge: TCP port 179—incremental updates RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
4
Prerequisites • Understand BGP attributes: ASPATH, NEXT_HOP, MED, LOCAL_PREF—allow routing policy via route-map. • Understand the bestpath decision algorithm • Know why to turn off synchronization and auto-summary!
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
5
Overview • Protocol Overview • Using BGP Attributes • Deploying IBGP • Deploying EBGP Connecting to an ISP Being an ISP
• Focus on Stability, Scalability, and Configuration Templates RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
6
Complex Network Scalability
Scalable Stable Simple RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
7
Recap of BGP What Is it? Why Use it?
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
8
Basic to Basics Peering C
A
AS 101
AS 100 D
B
• Runs over TCP—port 179 • Path vector protocol • Incremental updates
E
AS 102
• “Internal” and “External” BGP RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
9
General Operation
• Learns multiple paths via internal and external BGP speakers • Picks THE bestpath, installs it in the IP forwarding table, forwards to EBGP neighbors (not IBGP) • Policies applied by influencing the bestpath selection
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
10
BGP Sessions—TCP Port 179, 4 Basic Message Types
• 1: OPEN MESSAGE Exchange AS, router ID, holdtime Capability negotiation
• 2: NOTIFICATION Example: “peer in wrong AS”
• 3: KEEPALIVE—when no updates • 4: UPDATES (incremental)
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
11
BGP Attributes—Tools for Routing Policy
RST-243
1: ORIGIN
7: AGGREGATOR
2: AS-PATH
8: COMMUNITY
3: NEXT-HOP
9: ORIGINATOR_ID
4: MED
10: CLUSTER_LIST
5: LOCAL_PREF
14: MP_REACH_NLRI
6: ATOMIC_AGGREGATE
15: MP_UNREACH_NLRI
© 2002, Cisco Systems, Inc. All rights reserved.
12
Why Use It?
• You need to scale your IGP • You’re a multihomed ISP customer • You need to transit full Internet routes
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
13
Deploying BGP Turn of the Archaic Features!
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
14
BGP Template - BGP Global Settings router bgp 1 bgp deterministic-med no synchronization no auto-summary distance 200 200 200
For BGP config templates from now on, I’ll assume you’ve already done this!
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
15
Deploying Internal BGP Loopbacks, Peer-Groups, Route Reflectors and Confederations
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
16
Guidelines for Stable IBGP • IBGP peer using loopback addresses neighbor { ip address | peer-group} update-source loopback0 • Independent of physical interface failure • IGP performs any load-sharing • IBGP only—use on RR clients with care!!!
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
17
Peering with Loopbacks Without Loopbacks, the TCP Session Is Always Sourced from the IP Address of the Outbound Interface— Which Can Go Down!
A
B
• Configuration: Router A router bgp 1 neighbor 1.0.1.1 remote-as 1 Router B router bgp 1 neighbor 1.0.1.2 remote-as 1
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
1.0.1.1
1.0.1.2
If Redundant Paths Exist, Use Loopback Interfaces to Establish the Session
18
Guidelines for Scaling IBGP
• Carry only next-hops in IGP • Carry full routes in BGP only if necessary • Do not redistribute BGP into IGP • Use peer groups and RRs
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
19
BGP Template—IBGP Peers IBGP Peer Group AS1 router bgp 1 neighbor internal peer-group neighbor internal description ibgp peers neighbor internal remote-as 1 neighbor internal update-source Loopback0 neighbor internal next-hop-self neighbor internal send-community neighbor internal version 4 neighbor internal password 7 03085A09 neighbor 1.0.0.1 peer-group internal neighbor 1.0.0.2 peer-group internal RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
20
What Is a Peer Group?
• Simplifies configuration • All peer-group members have a common outbound policy • Updates generated once per peer group • Members can have different inbound policy
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
21
Why Route Reflectors? Avoid n(n-1)/2 iBGP Mesh
13 Routers => 78 IBGP Sessions!
n=1000 => Nearly Half a Million iBGP Sessions!
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
22
Using Route Reflectors RR
RRC
Backbone RR
RR
RRC
Cluster A
RRC
RR
RR
Cluster C Golden Rule of RR Loop Avoidance:
Cluster B RRC
“RR Topology Should Follow Physical Topology” => Be Careful with Loopback Peering!!!! RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
RR
Cluster D 23
Route Reflectors • Provide additional control to allow router to advertise (reflect) iBGP learned routes to other iBGP peers Method to reduce the size of the iBGP mesh
• Normal BGP speakers can coexist Only the RR has to support this feature neighbor x.x.x.x route-reflector-client
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
24
Route Reflectors—Terminology Non-client
Route Reflector
Clusters Clients
Clients
Lines Represent Both Physical Links and BGP Logical Connections RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
25
Route Reflectors—Terminology (Cont.) • Route reflector Router that reflects the iBGP information
• Client Routers between which the RR reflects updates (may be fully meshed among themselves)
• Cluster Set of one or more RRs and their clients (may overlap)
• Non-client iBGP neighbour outside the cluster RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
26
What Is a Route Reflector?
• Reflector receives path from clients and non clients • If best path is from a client, reflect to clients and non-clients • If best path is from a non-client, reflect to clients
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
27
Route Reflectors—Hierarchy
• Clusters may be configured hierarchically RRs in a cluster are clients of RRs in a higher level
Level 1
Level 2
Provides a “natural” method to limit routing information sent to lower levels
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
28
Deploying Route Reflectors • Divide backbone into multiple clusters • Each cluster contains at least one RR; Clients can peer with RRs in other clusters for redundancy • RRs are fully meshed via IBGP • Still use single IGP—next-hop unmodified by RR; unless via explicit inbound route-map
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
29
Route Reflectors—Migration • Where to place the route reflectors? Follow the physical topology! This will guarantee that the packet forwarding won’t be affected
• Configure one RR at a time Eliminate redundant iBGP sessions Place one RR per cluster
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
30
Route Reflectors—Migration • Step 0: full iBGP mesh
A
B
E
C
D
Logical Links Physical AND Logical Links RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
31
Route Reflectors—Migration • Step 1: configure D as a RR; E is the client
A
B
E
C
D
RR
Logical Links Physical AND Logical Links RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
32
Route Reflectors—Migration • Step 2: eliminate unnecessary iBGP links
A
B
E
C
D
RR
Logical Links Physical AND Logical Links RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
33
Route Reflectors—Migration • Step 3: repeat for other clusters and iBGP links
A
RR
E
B
C
D
RR
RR
Logical Links Physical AND Logical Links RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
34
BGP Template: Peer-Group for RR Clients router bgp 1 Will this Break the neighbor rr-client peer-group “Golden Rule?” neighbor rr-client description RR clients neighbor rr-client remote-as 1 neighbor rr-client update-source Loopback0 neighbor rr-client route-reflector-client This Line on RRs neighbor rr-client next-hop-self Only RRCs Use Still Use Internal neighbor rr-client send-community Peer Group neighbor rr-client version 4 neighbor rr-client password 7 03085A09 neighbor 10.0.1.1 peer-group rr-client neighbor 10.0.1.2 peer-group rr-client RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
35
RR Specific BGP Attributes RR 1.4.1.1
Router id 1.3.1.1
RRC Router id
A
1.2.1.1
C
• Example: RouterB>sh ip bgp 3.0.0.0 B BGP routing table entry for 3.0.0.0/8 3 1.0.1.2 from 1.4.1.1 (1.1.1.1) Origin IGP, metric 0, localpref 100, valid, internal, best
Router id 1.1.1.1
RRC D
1.0.1.2
Originator: 1.1.1.1 Cluster list: 1.3.1.1, 1.2.1.1
RR
AS3 3.0.0.0
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
36
BGP Attributes: ORIGINATOR_ID • ORIGINATOR_ID Router ID of IBGP speaker that injects route into AS—applied by RR
• Useful for troubleshooting and loop detection
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
37
BGP Attributes: CLUSTER_LIST • CLUSTER_LIST String of CLUSTER_IDs through which the route has passed
• Usually CLUSTER_ID=ROUTER_ID • Overridden by: bgp cluster-id x.x.x.x—but remember: don’t do this!!!! • Useful for troubleshooting and loop detection RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
38
Route Reflectors—Redundancy • Multiple RRs can be configured in the same cluster—but we now advise against this Other RRs in the same cluster should be treated as iBGP peers (non-clients) All RRs in the cluster must have the same cluster-id
• A router may be a client for RRs in different clusters RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
39
Multiple Route Reflectors cluster-id 3.0.0.1 1.0.0.1
RR2 routerB>sh ip bgp 10.0.0.0 BGP routing table entry for 198.10.10.0/24 3 B 2.0.0.2 from 1.0.0.1 (1.0.1.1) Origin IGP, metric 0, localpref 100, valid, internal, best Originator: 1.0.1.1 Cluster list: 3.0.0.1 If A and C have the same CLUSTER_ID, C will not reflect routes from A to B ( ignored due to 3.0.0.1 in the CLUSTER_LIST) ⇒If the direct links C-D and B-A fail, D cannot reach 10.0.0.0 RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
RR1
1.0.1.1
eBGP 2.0.0.2 10.0.0.0/24
Lines Represent Both Physical Links and BGP Logical Connections 40
Route Reflectors—Results • Number of neighbors is reduced No need for full iBGP mesh
• Number of routes propagated is reduced Each RR advertises only the best path to its clients
• Stability and scalability are achieved!
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
41
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
• Usually a single IGP
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
42
Confederations (Cont.) • Visible to outside world as single AS— “Confederation Indentifier” Each sub-AS uses a number from the private space
• iBGP speakers in sub-AS are fully meshed The total number of neighbors is reduced by limiting the full mesh requirement to only the peers in the sub-AS
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
43
Confederations (Cont.) Sub-AS 65530 AS 2
B Sub-AS 65532
Sub-AS 65531
• Configuration (rtr B): router bgp 65532 confederation identifier 2 bgp confederation peers 65530 65531 neighbor 141.153.12.1 remote-as 65530 neighbor 141.153.17.2 remote-as 65531 RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
44
Route Propagation Decisions • Same as with “normal” BGP: From peer in same sub-AS → only to external peers From external peers → to all neighbors
• “External peers” refers to Peers outside the confederation Peers in a different sub-AS Preserve LOCAL_PREF, MED and NEXT_HOP RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
45
Confederations (Cont.) • Example (cont.): BGP table version is 78, local router ID is 141.153.17.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete
RST-243
Network
Next Hop
*> 10.0.0.0
141.153.14.3
0
100
0
(65531) 1 i
*> 141.153.0.0 141.153.30.2
0
100
0
(65530) i
*> 144.10.0.0
141.153.12.1
0
100
0
(65530) i
*> 199.10.10.0 141.153.29.2
0
100
0
(65530) 1 i
© 2002, Cisco Systems, Inc. All rights reserved.
Metric LocPrf Weight Path
46
RRs or Confederations
Internet Connectivity
Multi-Level Hierarchy
Policy Control
Scalability
Migration Complexity
Confederations
Anywhere In the Network
Yes
Yes
Medium
Medium To High
Route Reflectors
Anywhere In the Network
Yes
Yes
Very High
Very Low
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
47
More Points about Confeds • Can ease “absorbing” other ISPs into you ISP—eg, if one ISP buys another (can use local-as feature to do a similar thing) • You can use route-reflectors within confederation sub-as to reduce the sub-as ibgp mesh
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
48
So Far… • Is IBGP peering Stable? Use loopbacks for peering
• Will it Scale? Use peer groups Use route reflectors
• Simple, hierarchical config?
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
49
COMMUNITIES They’re for Everyone!
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
50
Problem: Scale Routing Policy Solution: COMMUNITY • NOT in decision algorithm • BGP route can be a member of many communities • Typical communities: Destinations learned from customers Destinations learned from ISPs or peers Destinations in VPN—BGP community is fundamental to the operation of BGP VPNs RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
51
Problem: Scale Routing Policy Solution: COMMUNITY Communities: 1:100—Customer Routes 1:80— ISP Routes
ISP 2
ISP 1
ISP 4
ISP 3 0.0.0.0
Customer 1 (no Default, Wants Full Routes) RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
Customer 2 (Uses Default, Wants Your Routes) 52
Problem: Scale Routing Policy Solution: COMMUNITY Communities: 1:100—Customer Routes 1:80— ISP Routes
Set Community 1:80
ISP 1 Match Community 1:100 1:80
ISP 3
Match Community 1:100
Match Community 1:100
Set Community 1:100
Customer 1 (no Default, Wants Full Routes) RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
ISP 2
ISP 4 0.0.0.0
Customer 2 (Uses Default, Wants Your Routes) 53
BGP Attributes: COMMUNITY
• Activated per neighbor/peer-group: neighbor {peer-address | peer-group-name} send-community
• Carried across AS boundaries • Common convention is string of four bytes:
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
54
BGP Attributes: COMMUNITY (Cont.) • Each destination can be a member of multiple communities • Using a route-map: set community <1-4294967295> community number
RST-243
aa:nn
community number in aa:nn format
additive
Add to the existing community
none
No community attribute
local-AS community)
Do not send to EBGP peers (well-known
no-advertise community)
Do not advertise to any peer (well-known
no-export community)
Do not export outside AS/confed (well-known
© 2002, Cisco Systems, Inc. All rights reserved.
55
Community Filters • Filter based on Community Strings ip community-list <1-99> [permit|deny] comm ip community-list <100-199> [permit|deny] regexp
• Per neighbor Inbound or outbound route-maps match community
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
56
Community Filters • Example 1: Mark some prefixes as part of the 1:120 community (+remove existing community!)
• Configuration: router bgp 1 neighbor 10.0.0.1 remote-as 2 neighbor 10.0.0.1 send-community neighbor 10.0.0.1 route-map set_community out ! route-map set_community 10 permit match ip address 1 set community 1:120 ! access-list 1 permit 10.10.0.0 0.0.255.255 RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
57
Community Filters • Example 2: Set LOCAL_PREF depending on the community that the prefix belongs to.
• Configuration: router bgp 1 neighbor 10.0.0.1 remote-as 2 neighbor 10.0.0.1 route-map filter_on_community in ! route-map filter_on_community 10 permit match community 1 set local-preference 150 ! ip community-list 1 permit 2:150 RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
58
Regular Expression Syntax—URL • Overview of IOS regular expression syntax: http://www.cisco.com/univercd/cc/td/doc/prod uct/software/ios11/arbook/arapptrn.htm
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
59
Deploying External BGP for Enterprises Aggregation, Policy, and Loadsharing
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
60
Tasks • Steps Configure neighbor Advertise stable prefixes to your ISP Set inbound policy Set output policy Configure loadsharing/multi-homing
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
61
BGP Template: BGP to an ISP AS 2
Router B: router bgp 1 10.0.0.0 network 10.60.0.0 mask 255.255.0.0 .1 A neighbor external peer-group neighbor external remote-as 2 AS 1 Is a Customer neighbor external description ISP connection of ISP AS 2 neighbor external remove-private-AS neighbor external version 4 10.200.0.0 neighbor external prefix-list ispout out ; “accident” filter neighbor external route-map ispout out ; “real” filter neighbor external route-map ispin in .2 B neighbor external password 7 020A0559 10.60.0.0/16 neighbor external maximum-prefix 65000 [warning-only] AS1 neighbor 10.200.0.1 peer-group external ip route 10.60.0.0 255.255.0.0 null0 254 RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
62
Neighbor Template: Notes The slide shows a “complete” EBGP configuration. Notice that it has quite a few more features enabled than the simple configuration I gave at the start of the session. These features are not all mandatory—they are suggestions, and you should read the justifications that follow to see if they make sense in your network. I begin my generating a stable aggregate (or supernet) route that covers all of the subnets in my network. There is no need for the Internet to know about more specific routes in my network, and I do not want to “flap” routes as these individual subnets may come and go within my network. First, even though there is only one neighbor, I define a peer group. This does no harm, and may remind me to re-use the peer-group if I have a another session to the same ISP (with the same outbound policy), thereby obtaining the update generation efficiency that comes with this feature. Next, I define the remote-as 2, and the provide a text description. I also instruct the neighbor to remove any private AS numbers (64512-65535). Although not strictly necessary if you are not using private AS, this is a nice safeguard should you ever decide to use private AS numbers in your network, and forget to update your outbound policy accordingly. I lock down the BGP version to version 4, to guard against the hopefully rare, but possible, outcome the ISP configures their sessions with version 3 (call me paranoid :-) ). RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
63
Neighbor Template: BGP to an ISP Now I apply the routing policy. Because I’m paranoid, I double-up on the outbound policy. I apply a route-map containing a community list as my “primary” filter; however I back this up with a prefix list. This is only really feasible if you are an enterprise and the number of entries in the prefix-list is small. For an ISP, you will probably just use a community list, and extreme care!!! I apply an inbound policy, which essentially prevents me against mistakes my ISP make make, such as sending me my own routes, sending me private IP address space (eg network 10.0.0.0 etc). Speaking of mistakes: what if the ISP messes up their outbound policy and sends me more routes than the memory in my router can take? If this router is not only connecting me to the outside world, but also performing critical routing functions WITHIN my network, it would be bad for a problem with the ISP to disrupt internal network connectivity. I protect my router against this by using the “maximumprefix” command. I know roughly how many routes my ISP should be sending me, and I choose a number a little higher than this—if the ISP sends me more, then the router will close down the session, and keep it down until I issue a “clear ip bgp 10.200.0.1”. Alternatively, if I know that network management is quick to respond to problems, I could just configure the command to log a warning instead. Finally, I apply a password, negotiated with my ISP, to the session. RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
64
Maximum Prefix Tracking (Cont.) • Sample logs: The number of prefixes received from a peer reaches 75% of the maximum configured: %BGP-4-MAXPFX: No. of prefix received from 44.1.1.2 reaches 3, max 4 The number of prefix exceeds the maximum number of prefixes configured: %BGP-3-MAXPFXEXCEED: No. of prefix received from 44.1.1.2: 4 exceed limit 3
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
65
Tasks • Steps Configure neighbor Advertise stable prefixes to your ISP Set inbound policy Set output policy Configure loadsharing/multi-homing
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
66
Advertise Stable Prefixes to Your ISP
• Avoid redistribution—it propagates IGP instabilities to the Internet; Unstable routes may be dampened! • Try to summarize! • For loadsharing, may split the aggregate—more later
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
67
BGP Template: BGP to an ISP The first instinct for many people is to redistribute their IGP into BGP. This is a bad idea for a couple of reasons: First, IGPs tend to have a lot our routing activity as they route-around network failures. This is the good an dproper behavior of an IGP. However, one of primary goals of BGP is to hide “internal” rouring changes to your network that have no impact on global routing. Remember it is common practice by ISPs in the Internet to “dampen” unstable routes learned from the customers of other ISPs. Second, the subnetting used by an IGP is probably not of interest to the wider Internet. As with good IGP design, you should attempt to “summarize” you routes, so that you advertise the minimum number of routes to the Internet routing tables. It’s everyone’s responsibility to try and minimize the size of the Internet routing tables. You can also use a route-map to adjust other BGP attributes. For example, you may connect to your ISPs in two location, and generate two aggregates. You can set the MEDs so that traffic for one aggregate will come into one link, and traffic to the other will come in the other link (with both links providing a backup to the other). Now I apply the routing policy. RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
68
Why Summarize?
• Reduce number of Internet prefixes • Increase stability—aggregate stays even if specifics come and go
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
69
How to Summarize? • Use the “network” statement to define prefix—can add route-map • network statement only installs BGP route if there is a matching route in IGP => lock down a stable static to null0; set admin distance to 254 so it does not override any “real” IGP route router bgp 1 network 10.60.0.0 mask 255.255.0.0
© 2002, Cisco Systems, Inc. All rights reserved.
70
Tasks • Steps Configure neighbor Advertise stable prefixes to your ISP Set inbound policy Set output policy Configure loadsharing/multi-homing
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
71
Why Inbound Policy?
• Apply a recognizable community to use in outbound filters or other policy • Apply local preferences • Filter our you own/martian routes • Multihoming loadsharing—more later
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
72
BGP Template—Inbound Policy
route-map ISPin permit deny 10 match ip address prefix-list ISPout sanity-check route-map ISPin permit 20 set local-preference 200 routes from ISP—you could use the“no-export” well set community 1:2 known community instead
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
73
Notes on Inbound Policy Template Now let’s look at inbound policy. The roles of inbound policy are to protect you against mistakes made by your ISP; to place routes into communities for subsequent use in outbound policy; and to modify BGP attributes to allow us to control which exit we use to send traffic to various destinations on the Internet. To implement inbound policy I apply a route-map to the peer-group. Remember than inbound-policy does NOT have to be the same for all peer-group members, so I can apply different policies to different neighbors within a peer-group. The route-map, which I’ve call ISPin does three things: 1) rejects any networks in prefix-list ISPout—this prefix lists contains the prefixes I send to my ISP, so I should not expect to receive them back. I also call a prefix list that rejects private address space and other “insane” or “martian” (not on this planet!) routes. 2) applied a local-preference of 200 to all of the routes—perhaps because this exist point is the primary exit point, and another connection to my ISP is the backup, and uses the default local-preference of 100. 3) Put the routes in community 1:2, which signifies “routes I’ve learned from my ISP”. RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
74
Sanity-Check Prefix-List 1/2 ip prefix-list sanity-check seq 5 deny 0.0.0.0/32 # deny the default route - YOU MAY WANT TO OMIT THIS LINE ip prefix-list sanity-check seq 10 deny 0.0.0.0/8 le 32 # deny anything beginning with 0 ip prefix-list sanity-check seq 15 deny 0.0.0.0/1 ge 20 # deny masks > 20 for all class A nets (1-127) ip prefix-list sanity-check seq 20 deny 10.0.0.0/8 le 32 # deny 10/8 per RFC1918 ip prefix-list sanity-check seq 25 deny 127.0.0.0/8 le 32 # reserved by IANA - loopback address ip prefix-list sanity-check seq 30 deny 128.0.0.0/2 ge 17 deny masks >= 17 for all class B nets (129-191) ip prefix-list sanity-check seq 35 deny 128.0.0.0/16 le 32 # deny net 128.0 - reserved by IANA ip prefix-list sanity-check seq 40 deny 172.16.0.0/12 le 32 # deny 172.16 as RFC1918 RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
75
Sanity-Check Prefix-List 2/2 ip prefix-list sanity-check seq 45 deny 192.0.2.0/24 le 32 # class C 192.0.20.0 reserved by IANA ip prefix-list sanity-check seq 50 deny 192.0.0.0/24 le 32 # class C 192.0.0.0 reserved by IANA ip prefix-list sanity-check seq 55 deny 192.168.0.0/16 le 32 # deny 192.168/16 per RFC1918 ip prefix-list sanity-check seq 60 deny 191.255.0.0/16 le 32 # deny 191.255.0.0 - IANA reserved (I think) ip prefix-list sanity-check seq 65 deny 192.0.0.0/3 ge 25 # deny masks > 25 for class C (192-222) ip prefix-list sanity-check seq 70 deny 223.255.255.0/24 le 32 # deny anything in net 223 - IANA reserved ip prefix-list sanity-check seq 75 deny 224.0.0.0/3 le 32 # deny class D/Experimental RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
76
Tasks • Steps Configure neighbor Advertise stable prefixes to your ISP Set inbound policy Set output policy Configure loadsharing/multi-homing
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
77
Why Outbound Policy? • Main filter based on communities • Adding a prefix filter helps protect against mistakes (can apply as-path filters too) • Send community based on agreements with ISP—eg RFC1998 (remember to config send-community) • Multihoming loadsharing policy
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
78
Notes On Outbound Policy Now that inbound policy is set, I next setup the outbound policy. A common mistake made by many enterprises that dual home it to take a full set of routes from one ISP, and immediately send them up to the other ISP. This effectively says the entire Internet is reachable through your network!!! Outbound policy prevents this from occurring, so you can see why it’s critical. I typically use primary outbound filter based on communities. I only send to my ISP all of the routes originated in my network, which I identify with the community 1:1. In smaller installations, where the number of prefixes in the network is small, I may also use a prefix-list as a “backup” for the primary community filter. This does nothing more than to help protect the world against my mistakes!!! :-) I may also have configured some communities in agreement with my ISP. For example, RFC1998 describes a way to indicate which of your ISPs is primary a secondary for a particular set of routes. Finally, you can configure any multihoming/loadsharing policy. You may want to divide your address space, and make traffic to half of your network come in via one ISP, and traffic for the other half come in through the other.
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
79
BGP Template—Outbound Policy
ip prefix-list ISPout seq 5 permit 10.60.0.0 255.255.0.0 : ip community-list 1 permit 1:1 ; all routes to send to ISP : route-map ISPout permit 10 match community 1 ; Internet transit community set community 1:3 [additive] ; something agreed with ISP
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
80
Notes On Outbound Policy
The previous slide shows my outbound policy. First, the prefix-list ISPout matches all of the routes I intend to send to the Internet—in this case only one—life is simple in the powerpoint world of network design :-) This prefix-list is my “backup” in case I make a mistake with communities. I only used it on my connections to my ISP. The primary filter is based on communities. I match all communities in communitylist 1: ie, only community 1:1, corresponding to all the routes local to my network. This assumes that on ingress to by BGP tables (either via EBGP sessions, “network/aggregate-address”, or redistribution from an IGP, I have used a routemap to set the community to 1:1. Finally I add the outbound community to 1:3 community attribute. This is done to meet some arbitrary agreement I’ve have made with my ISP on how it will treat routes I put in this community.
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
81
Tasks • Steps Configure neighbor Advertise stable prefixes to your ISP Set inbound policy Set output policy Configure loadsharing/multi-homing
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
82
Load-Sharing Template: Single Path Router A: interface loopback 0 ip address 1.0.0.1 255.255.255.255 ip route 2.0.0.1 255.255.255.255 serial0/0 ip route 2.0.0.1 255.255.255.255 serial0/1 ! router bgp 1 neighbor 2.0.0.1 remote-as 2 neighbor 2.0.0.1 update-source loopback0 neighbor 2.0.0.1 ebgp-multi-hop 2
A AS1 RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
B AS2
Loopback 0 2.0.0.1
83
Load-Sharing Template: Multiple Paths from Same AS Router A: router bgp 1 neighbor 2.0.0.1 remote-as 2 neighbor 2.0.0.2 remote-as 2 maximum-paths 2 ; can configure up to 6
B A AS 1
2.0.0.1
AS 2 C
2.0.0.2
• Outbound loadsharing works well :-) • Inbound loadsharing depends on ISP IGP :-| RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
84
What Is Multi-homing?
• Connecting to two or more ISPs to increase: Reliability—one ISP fails, still OK Performance—better paths to common Internet destinations
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
85
Types of Multi-homing
• Three common cases: Default from all ISPs Default + customer routes from all ISPs Full routes from all ISPs
• Look first at outbound loadsharing
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
86
Default from All ISPs
• Low memory/CPU solution • All ISPs send (or you generate) default • ISP decided by IGP metrics to reach default
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
87
Default from All ISPs Customer AS 4 4.0.0.0/8
ISP
ISP
AS 2
AS 3 D
E 0.0.0.0
0.0.0.0 A
B
AS 1 C RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
C Chooses Lowest IGP Metric to Default 88
Customer+Default from All ISPs
• Medium memory and CPU • “Best” path—usually shortest AS-path • Use local-preference to override based on prefix, as-path, or community • IGP metric to default used to reach nondirect customers of ISPs
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
89
Customer Routers from All ISPs Customer AS 4 4.0.0.0/8
ISP
ISP
AS 2
AS 3 D
C Chooses Shortest AS Path
E A
AS 1
B
C RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
90
Customer Routes from All ISPs Customer AS 4 4.0.0.0/8
ISP
ISP AS 2
AS 3 800
D
C Chooses Highest Local-Preference
A
AS 1 C
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
B
E
ip prefix-list AS4 permit 4.0.0.0/8 route-map AS3in permit 10 match ip address prefix-list AS4 set local-preference 800 91
Customer Routes from All ISPs Tier 1 ISP
Tier 1 ISP
AS 4
AS 5
Tier 2 ISP
Tier 1 ISP
AS 2
AS3 D
E
A AS400 Takes SubOptimal AS Path RST-243
AS 6
© 2002, Cisco Systems, Inc. All rights reserved.
AS 1
B
C 92
Full Routes from All ISPs
• Higher memory/CPU solution • Reach all destinations by “best” path—usually shortest AS path • Can still manually tune using local-pref and as-path/community/prefix matches
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
93
Full Routes from All ISPs Tier 1 ISP
Tier 1 ISP
AS 4
AS 5
Tier 2 ISP
Tier 1 ISP
AS 2
AS3 D
E
A C Chooses Shortest AS Path RST-243
AS 6
© 2002, Cisco Systems, Inc. All rights reserved.
AS 1
B
C 94
Controlling Inbound Traffic?
• Inbound is more difficult to control due to lack of a transitive metric • You can evenly divide outgoing address blocks across providers, but what happens to redundancy? • If you split your address block, ISPs may filter out the specifics anyway
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
95
Controlling Inbound Traffic? (Cont.) • Bad Internet citizen: Divide address space Set as-path prepend
• Good Internet citizen—RFC2260 Divide address space Use “advertise maps”
• Results may not be as good as NAT with transport level loadsharing Warning: if you split your address block using these techniques it may be filtered by some ISPs RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
96
Using AS-PATH Prepend Customer AS 100
to 10.1/16
10.1.0.0/16 3 1 1 10.1.0.0/16 2 1 (best) 10.2.0.0/16 3 1 (best) 10.2.0.0/16 2 1 1
ISP
ISP AS 2
AS 3 E
D A
B
AS 1 10.1/16
RST-243
C
10.2/16
© 2002, Cisco Systems, Inc. All rights reserved.
30.0.0.1
router bgp 1 neighbor 30.0.0.1 remote-as 3 neighbor 30.0.0.1 route-map AS3out out ip prefix-list AS1 permit 10.1.0.0/16 route-map AS3out permit 10 match ip address prefix-list AS1 set as-path prepend 1 97
Using an Advertise-Map router bgp 100 neighbor
1.10.6/24
10.15.7/24 R2
10.15.20/30 R4
AS 2
10.15.7/24
1.10.6/24 1.10.6.1
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
10.15.7.4 98
Summary for Enterprise EBGP • Stability through: Aggregation/summary routes Multihoming Inbound/outbound policy
• Scalability of memory/CPU: Default, customer routes, full routes
• Simplicity using “standard” solutions
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
99
Deploying External BGP for ISPs Route Aggregation, Customer Aggregation, NAPs
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
100
ISP EBGP Tasks
• Configure stable aggregates • Scale BGP customer aggregation • Offer a choice of route-feeds • Peer with other providers • Provide a backup service
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
101
What Is Aggregation? • Summarization based on specifics from the BGP routing table 10.60.1.0 255.255.255.0 10.60.2.0 255.255.255.240 => 10.60.0.0 255.255.0.0
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
102
How to Aggregate • aggregate-address 10.60.0.0 255.255.0.0 {as-set} {summary-only} {route-map} • Use as-set to include path and community info from specifics • summary-only suppresses specifics • route-map sets other attributes
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
103
How to Aggregate—Notes So what is aggregation? Aggregation is generating that all-important stable route that summarizes all of the routes I want to send to the Internet. My route is stable because it is common practice by ISPs in the Internet to “dampen” the routes learned from the customers of other ISPs. Generating a stable aggregating it a three step process. First I configure the “aggregate-address” command to define the aggregate prefix to be generated. The command includes both net and mask. If I include the “as-set” keyword, it causes the router to generate an AS-SET within the AS-PATH. Remember from earlier in the session, that an AS-SET includes ASPATH information from all more specific routes that contributed to the aggregate. As well as generating an AS-SET, the router will also include BGP community information from all of the more specific routes in the community attribute of the aggregate route. By default, the aggregate address command does NOT filter out the more specific BGP routes. TO do this you need to add the “summary-address” keyword. Mostly likely you will want to do this. You can also use a route-map to adjust other BGP attributes. For example, you may connect to your ISPs in two location, and generate two aggregate. You can set the MEDs so that traffic for one aggregate will come into one link, and traffic to the other will come in the other link (with both links providing a backup to the other). RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
104
Why Aggregate? • Reduce number of Internet prefixes— advertise only your CIDR block • Increase stability—aggregate stays even if specifics come and go • Stable aggregate generation: router bgp 1 aggregate-address 10.60.0.0 255.255.0.0 as-set summary-only network 10.60.1.0 255.255.255.0 : ip route 10.60.1.0 255.255.255.0 null0 254 RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
105
Why Aggregate: Notes Once you’ve configured the aggregate, the next step is to configure a stable MORE SPECIFIC route in the BGP table. After all, your aggregate depends on the existing of more specific routes, to you must ensure at least one of the more specific routes is stable. To do this, use the “network” command. Choose a more specific route than your aggregate—a route that is used somewhere in route network. In the slide I’ve chosen 10.60.1/24. The network command will install a corresponding route in the BGP table, ONLY if there is a matching route in the IP routing table. The third, and final step, is therefore to generate a stable route in the IP routing table. To do this, I configure a STATIC route for 10.60.1/24, pointing to the NULL0 interface. However, I do not want this route to override any “real” route that I’m learning via an IGP for 10.60.1/24—so, I set the ADMIN DISTANCE of the static route to 254. Note that if you do note want to generate AS-SET/community summary information, you can omit the aggregate-address command. Use the network command to generate the aggregate prefix, and then put a matching static route in pointing to NULL0. Many, perhaps most, folks tend to do it this way, and do not use the aggregate address command. Note that you need to be careful to filter out more specific BGP routes if you use this technique, as the network command does not provide any “summary-only” functionality. RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
106
BGP Attributes Atomic Aggregate
• Indicates loss of AS-PATH information • Must not be removed once set • Set by: aggregate-address x.x.x.x • Not set if as-set keyword is used, however, AS-SET and COMMUNITY then carries information about specifics
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
107
BGP Attributes: Aggregator
• AS number and IP address of router generating aggregate • Useful for troubleshooting • Only set by aggregate-address; NOT set by the network statement
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
108
Aggregate Attributes
NEXT_HOP = local (0.0.0.0) WEIGHT = 32768 LOCAL_PREF = none (assume 100) AS_PATH = AS_SET or nothing ORIGIN = IGP MED = none
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
109
ISP EBGP Tasks • Configure stable aggregates • Scale BGP customer aggregation • Offer a choice of route-feeds • Peer with other providers • Provide a backup service • Propagate QoS policy
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
110
Customer Aggregation Guidelines • Define at least three peer groups: cust-default—send default route only cust-cust—send customer routes only cust-full —send full Internet routes
• Identify routes via communities eg, 2:100=customers; 2:80=peers
• Apply passwords and an inbound prefixlist on a per neighbor basis RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
111
Customer Aggregation Your AS CIDR Block: 10.0.0.0/8
CORE Route Reflector
Aggregation Router (RR Client)
Full Routes “Default” Peer Group Peer Group
Client Peer Group
Customer Routes Peer Group
Apply Passwords and Inbound Prefix-list Directly to Each Neighbor RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
112
BGP template - customers neighbor x.x.x.x remote-as X neighbor x.x.x.x peer-group (cust-full or cust_cust or cust_default) neighbor x.x.x.x password <password> neighbor x.x.x.x prefix-list ASXXX in . ip prefix-list ASXXX seq 5 permit <prefix>
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
113
BGP template - full routes peer-group neighbor cust-full peer-group neighbor cust-full description Send full Routes neighbor cust-full remove-private-AS neighbor cust-full version 4 neighbor cust-full route-map cust-in in neighbor cust-full route-map full-routes out .
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
114
BGP template: full routes route-map ip prefix-list cidr-block seq 5 deny 10.0.0.0/8 ge 9 ip prefix-list cidr-block seq 10 permit 0.0.0.0/0 le 32 ip community-list 1 permit 2:100 ip community-list 80 permit 2:80 . route-map full-routes permit 10 match ip cidr-block
; deny CIDR subnets
match community 1 80
; customer & peers
set metric-type internal
; MED = IGP metric
set ip next-hop peer-address ; our own RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
115
BGP template: customer inbound route-map
route-map cust-in permit 10 set metric 4294967294 ; ignore MED set ip next-hop peer-address set community 2:100
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
116
BGP template: customer routes peer-group neighbor cust-cust peer-group neighbor cust-cust description customer routes neighbor cust-cust remove-private-AS neighbor cust-cust version 4 neighbor cust-cust route-map cust-in in neighbor cust-cust route-map cust-routes out
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
117
BGP Template: template: customer routes route-map
route-map cust-routes permit 10 match ip cidr-block match community 1 ; customers only set metric-type internal ; MED = igp metric set ip next-hop peer-address ; our own
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
118
BGP Template: default route peer-group neighbor cust-default peer-group neighbor cust-default description Send default neighbor cust-default default-originate route-map default-route neighbor cust-default remove-private-AS neighbor cust-default version 4 neighbor cust-default route-map cust-in in neighbor cust-default prefix-list deny-all out ip prefix-list deny-all seq 5 deny 0.0.0.0/0 le 32
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
119
ISP EBGP Tasks
• Configure stable aggregates • Scale BGP customer aggregation • Offer a choice of route-feeds • Peer with other providers
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
120
Peering with other ISPs
• Similar to EBGP customer aggregation except inbound prefix filtering is rarely used (lack of global registry) • Use maximum-prefix and prefix sanity checking instead • Still use per-neighbor passwords!
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
121
BGP Template: ISP peers peer-group neighbor nap peer-group neighbor nap description for peer ISPs neighbor nap remove-private-AS neighbor nap version 4 neighbor nap prefix-list sanity-check in neighbor nap prefix-list cidr-block out neighbor nap route-map nap-out out neighbor nap maximum prefix 30000
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
122
BGP Template: ISP peers route-
route-map nap-out permit 10 match community 1 ; customers only set metric-type internal ; MED = IGP metric set ip next-hop peer-address ; our own
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
123
Peer Groups for NAPs: Sanity-Check Prefix-List # FIRST - FILTER OUT YOUR IGP ADDRESS SPACE!! ip prefix-list sanity-check seq 5 deny 0.0.0.0/32 # deny the default route ip prefix-list sanity-check seq 10 deny 0.0.0.0/8 le 32 # deny anything beginning with 0 ip prefix-list sanity-check seq 15 deny 0.0.0.0/1 ge 20 # deny masks > 20 for all class A nets (1-127) ip prefix-list sanity-check seq 20 deny 10.0.0.0/8 le 32 # deny 10/8 per RFC1918 ip prefix-list sanity-check seq 25 deny 127.0.0.0/8 le 32 # reserved by IANA - loopback address ip prefix-list sanity-check seq 30 deny 128.0.0.0/2 ge 17 deny masks >= 17 for all class B nets (129-191) ip prefix-list sanity-check seq 35 deny 128.0.0.0/16 le 32 # deny net 128.0 - reserved by IANA ip prefix-list sanity-check seq 40 deny 172.16.0.0/12 le 32 # deny 172.16 as RFC1918 RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
124
Peer Groups for NAPs: Sanity-Check Prefix-List ip prefix-list sanity-check seq 45 deny 192.0.2.0/24 le 32 # class C 192.0.20.0 reserved by IANA ip prefix-list sanity-check seq 50 deny 192.0.0.0/24 le 32 # class C 192.0.0.0 reserved by IANA ip prefix-list sanity-check seq 55 deny 192.168.0.0/16 le 32 # deny 192.168/16 per RFC1918 ip prefix-list sanity-check seq 60 deny 191.255.0.0/16 le 32 # deny 191.255.0.0 - IANA reserved (I think) ip prefix-list sanity-check seq 65 deny 192.0.0.0/3 ge 25 # deny masks > 25 for class C (192-222) ip prefix-list sanity-check seq 70 deny 223.255.255.0/24 le 32 # deny anything in net 223 - IANA reserved ip prefix-list sanity-check seq 75 deny 224.0.0.0/3 le 32 # deny class D/Experimental RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
125
Summary for Deploying EBGP • Stability through: Aggregation/summary routes Inbound prefix-filtering and passwords Apply “sanity-check” and maximum-prefix feature to ISP peering
• Scalability of memory/CPU: Three peer-groups for customers: Default, customer routes, full routes One peer group for ISP peers
• Simplicity using “standard” solutions RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
126
Session Summary 1 • Scalability: Use attributes, especially community Use peer groups and route reflectors
• Stability: Use loopback addresses for IBGP Generate aggregates/summary addresses Apply passwords Always filter inbound and outbound
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
127
Session Summary 2 • Simplicity—standard solutions: Three multihoming options Group customers into communities Apply standard policy at the edge Avoid “special configs” Script your config generation
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
128
For Further Reference: • BGP bestpath http://www.cisco.com/warp/public/459/25.shtml
• Case studies on www.cisco.com: http://www.cisco.com/warp/public/459/18.html
• www.cisco.com—search “BGP
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
129
Recommended Reading Cisco BGP-4 Command and Configuration Handbook ISBN: 1-58705-017-X Advanced IP Network Design ISBN: 1-57870-097-3 Internet Routing Architectures ISBN: 1-57870-233-X Routing TCP/IP, Volume II ISBN: 1-57870-089-2 Troubleshooting IP Routing Protocols ISBN: 1-58705-019-6 Available online or on-site at the Cisco Company Store RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
130
Deploying BGP-4 RST-243
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
131
Please Complete Your Evaluation Form RST-243
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
132
Session Number Presentation_ID
© 2002, Cisco Systems, Inc. All rights reserved.
133
RST-243
© 2002, Cisco Systems, Inc. All rights reserved.
134
Related Documents
Deploying Bgp4 (rst-243)
December 2019 1
Deploying Bgp4 Teichtahl
December 2019 1
Deploying Ias
November 2019 12
Deploying Wins
November 2019 19
Deploying Dhcp
November 2019 9