(taken from http://puck.nether.net/bgp/cisco-config.html and give credit to punk.nether.net community!!)
Due to the ease of configuring bgp, it is easy to leave out critical steps that will result in some unintended consequences. There are a number of cases that exist persistently in the routing tables where some small network is actually connecting two “larger” networks together for some routes/prefixes for various reasons.
NOTE: Your ISP may have referred you here if you were detected to be involved in a routing leak.
As a result of this, and the ease of these errors/mistakes, we wanted to provide a few simple examples that would ease most networks configuration needs and provide a common reference.
These examples cover a few basic bgp related topics, including:
Some requirements for these examples, make sure the following are configured on your router(s):
Router(config)#ip bgp-community new-format Router(config)#router bgp xxx Router(config-router)#bgp always-compare-med Router(config-router)#bgp bestpath med confed Router(config-router)#bgp log-neighbor-changes Router(config-router)#no auto-summary Router(config-router)#no synchronization
This enables the usage of bgp communities in your configuration files in the asn:xxx format which ease their readability as compared to a “really big” number. The BGP specific config(s) will help in debugging, as well as provide for a more normalized and deterministic bgp decision process. It should be noted that these changes should perhaps not be made during any mission-critical time of day unless you are prepared to find the console quickly ;).
These examples also assume a simple model, that i've placed in the following table. The basic premise is that you want to send traffic to your customers before you send it to peers before you send it to your transit(s). This means send it to those that pay you to the increasing cost of those places that bill you. While you may think that bgp will automatically do this for you, it may not do it exactly as you expect. It's generally much better to configure this explicitly.
| Type | Local Pref | Community |
|---|---|---|
| Transit | 80 | xxx:180 |
| Peer | 100 | xxx:200 |
| Customer | 120 | xxx:220 |
(xxx in this case would be your asn. If your ASN were 701, that would be 701:220 for your customer routes.)
Now for the more specific BGP configs, you will want to start with your customer links and move towards your peers and transit links. This will keep their local-prefernece higher than the default (100) and start to tag their routes with the community that says you want to send it to your upstreams/peers.
router bgp xxx neighbor 1.2.3.4 remote-as 267 neighbor 1.2.3.4 prefix-list AS267-in in neighbor 1.2.3.4 route-map customer-in in neighbor 1.2.3.4 route-map customer-out out ! route-map customer-in set community xxx:220 set local-preference 120 ! route-map customer-out match community cust-out ! ip community-list expanded cust-out permit xxx:220 ip community-list expanded cust-out permit xxx:200 ip community-list expanded cust-out permit xxx:180 ! ip prefix-list AS267-in seq 5 permit 204.42.0.0/16 ip prefix-list AS267-in seq 10 deny 0.0.0.0/0 !
So, this does a few things for you. First, it only sends them prefixes that match your transit, peer and customer routes that have been tagged with these communities. It also sets their routes with the customer (xxx:220) community, and sets the prefernece internally to 120. This will also go to your other internal bgp peers (if any) within your ibgp mesh. You want to populate the AS267-in prefix-list with those routes that you want to accept from your customers. You don't want to accept all routes, as they may have misconfigured their router to send you some of their peer or transit routes that they are not expecting to go via this link. I listed an example prefix above, with an explicit deny at the end.
Now that you've tagged your customer routes, you may want or need to tag your itnernal routes as well with the appropriate community. The best way to do this is to have a route-map that matches against a prefix-list that contains your aggregate routes. This is currently left as an excersise for the reader to implement, as there are numerous ways to announce, including connected (Null0) routes, aggregate and other ways to originate the routes.
Tagging your transit and peer routes is perhaps the most important thing to do. You don't want to leak one transit/peer to another (unless you have some very specific needs).
Following the above configuration example for a customer routes, the natural evolution is the following configuration example:
router bgp xxx neighbor 1.2.3.4 remote-as 267 neighbor 1.2.3.4 route-map peer-in in neighbor 1.2.3.4 route-map peer-out out ! route-map peer-in set community xxx:200 set local-preference 100 ! route-map peer-out match community peer-out ! ip community-list expanded peer-out permit xxx:220 !
This matches just routes that were tagged with the “220” community, which would be your internal+customer routes. You could tag your internal routes with some additional new community you create to make them show up differently from your “customer” prefixes. If so, add those to your peer-out community-list.
Transit routes generally are identical to peer routes, but you may want to do soemthing different with them in the future so it's ideal to have a different route-map and community-list for manipulating those announcements. If you're trying to go easy on this all, here is the cut+paste that may help you out:
router bgp xxx neighbor 1.2.3.4 remote-as 267 neighbor 1.2.3.4 route-map transit-in in neighbor 1.2.3.4 route-map transit-out out ! route-map transit-in set community xxx:180 set local-preference 80 ! route-map transit-out match community transit-out ! ip community-list expanded transit-out permit xxx:220 !