So after working the BGP labs from INE, I came across some gotchas, some oh crap moments, and some what the hell was I thinking. Below are those times so that I can relive them over and over.
BGP auto-summarization only happens if there is a network command with a classful subnet or if prefixes are redistributed into BGP. With the network statement, the aggregate is installed into the BGP table if there is a subnet of the prefix in the IGP table. Also auto-summarized routes do not have the aggregator or atomic aggregator attributes in them. This happens because of where the summarization is is performed. It does it on the IGP prefixes and not the BGP prefixes.
Best-path selection excludes some prefixes based on certain criteria:
1. No valid next-hop. If you can't get to the next-hop, how can it be the best-path. Duh. That is hy for eBGP neighbors, you may want to include next-hop-self
2. BGP synchronization is enabled and the prefix is not found in the IGP table. Basic synchronization there. Thank goodness it is off by default.
3. The received prefix has your AS number. Must have come from you so goodbye.
BGP best-path looks at the following list to determine what is a better way to send that prefix out.
1. Ignore paths that don't work. See above list.
2. Highest weight. (Time where more weight is a good thing).
3. Highest local preference
4. Locally originated prefixes. Come in by network, aggregate-address, or redistribution commands.
5. Shortest AS-Path.
6. Lowest Origin Type code where IGP < EGP < Incomplete
7. Lowest MED, so long as the first AS is the same
8. External BGP routes over Internal BGP routes
9. Smallest IGP metric to next-hop
10. Lowest BGP originating router-id
By default MED is only compared when the prefix is received from the same AS. If the prefix comes from into you from AS 54 and 55, then it won't be used. But if they both list AS 54 as the first AS, then it can be.
You can route based on the IGP or the MED. If you use the IGP, that is "hot potato" routing and "cold potato" routing using the MED. With the IGP, you want that traffic away from you as soon as possible. With MED, you are willing to hold onto it a little longer.
If a path contains route reflector attributes (Originator-ID, Cluster-ID), the originator ID is substituted for the router ID in the path selection process. But if you make it this far down the list for the best-selection, then wow. That is one heck of a selection.
So, you have prefixes that are failing to show up in the route table. You check the BGP table and you see that there are RIB failures. Why? Well, there is a command to see why. Use show bgp ipv4 unicast rib-failure and it will out put the following (or something close):
R1#show bgp ipv4 unicast rib-failure
Network Next Hop RIB-failure RIB-NH Matches
150.1.77.0/24 155.1.13.3 Higher admin distance n/a
So, I had a major brain fart. I had to aggregate some routes. No issue, right? Do aggregate-address under the BGP process and all is good? Nope. I did a stupid mistake and forgot about getting the routes into to the BGP table first. Doh!!
There are routes coming into your router or your AS that have communities set. You want a clean slate. Under a route-map use set community none. I was trying to use a no set community no-export. That didn't work.
The advertise-map option of aggregate-address is for showing what prefixes are added to an aggregate.
I got so focused in setting community-lists that I forgot about the comm-list delete option for set in a route-map. Gotta read my command options more carefully in the documentation.
Conditional advertisements come from using an advertise-map with a neighbor statement. They can either be for as long as a prefix exists, broadcast this; or when this doesn't exist, broadcast this.
A BGP inject-map requires two route-maps. One to show what is being injected with any parameters as well. This is done with a set ip address prefix-list. The second route-map includes the match for the aggregated address with a match ip address prefix-list and the second requirement of a match ip route-source prefix-list, which matches where the aggregation originated from. This is not the next-hop but the aggregation origination. This source can change when moving from iBGP to eBGP. Inject maps are great for deconstructing an aggregation.
Filtering with BGP is applied in two different orders depending on the direction, inbound or outbound. Inbound does route-map, filter-list, prefix-list/distribution/list. Outbound does prefix-list/distribution-list, filter-list, and route-map.
So with the no-prepend option of neighbor local-as, the old AS is not prepended to the AS list. The new AS, the one configured with router bgp <AS>, is. This helps so that you can run a new AS number on your borders and run the old AS number internally until everyone is moved over. Without this, the internal routers would reject the route. This also only applies to inbound routes. All external routes have the old AS and the new AS prepended to the them.
Using the replace-as option with the no-prepend option of neighbor local-as, allows the router to replace all instances of the new AS number with the old one. This allows the new AS number to be hidden from the outside world.
The command bgp scan-time is used to adjust the amount of time that BGP process allows before initiating a scan of the BGP routing information. INE used it in their lab talking about the amount of time that the BGP process will wait to process a conditional route advertisement. I was looking for the advertisement coming in and they were talking about it going out. The defautl is 60 seconds.
Outbound route filtering (ORF) has to be applied using neighbor prefix-list in. Needs to be done once the capability has been enabled.
BGP ttl-security needs to be set the same on both sides of a link to make sure that the links stay secure and expect the same value. Also you can use it or ebgp-multihop but not both for the same neighbor.
The neighbor allowas-in is not in the BGP command-list. It is in the MPLS section instead. Makes sense when you think about it. The option is for discontinuous systems and that can happen easily with an MPLS backbone.
No comments:
Post a Comment