CCIE Study Notes

For all the routing protocols, we discussed how they connect to peers and how they determine the "best path" as seen by that protocol. BGP also has these mechanisms and they are things that I would consider fair game for the test.

Configuring BGP peers is easy. The part that you might see would involve the neighbor relationship. "A BGP peer uses a simple finite state machine (FSM) that consists of six states: Idle; Connect; Active; OpenSent; OpenConfirm; and Established." The Wikipedia page on BGP has a good explanation of this. You should have an idea of what happens in each state and in particular know that the first five states are setting up things - and the routes are not exchanged until the peer relationship is in the established state. If you've ever set up BGP and you're not getting your routes, you are probably familiar with this. Also know about soft resets.

So let's move on to how BGP selects a "best path" using the attribute values. Remember that a route to the next hop router must exist in the routing table. And IGP synchronization is either turned off or the route exists in your IGP (be it RIP, EIGRP or OSPF). These are mainly R/S items. The part that may be relevant to this exam is the way BGP selects the best path out of multiple routes to the same destination. It's a 12-step process.

1. If the next hop is inaccessible, do not consider it.
2. If the path is internal, synchronization is enabled, and the route is not in the IGP, do not consider the route.
3. Prefer the path with the largest weight (weight is a Cisco proprietary parameter).
4. If the routes have the same weight, prefer the route with the largest local preference.
5. If the routes have the same local preference, prefer the route that was originated by the local router.
6. If the local preference is the same, or if no route was originated by the local router, prefer the route with the shortest autonomous system path.
7. If the autonomous system path length is the same, prefer the route with the lowest origin code (IGP < EGP < INCOMPLETE).
8. If the origin codes are the same, prefer the route with the lowest MED metric attribute.
9. Prefer the external BGP (eBGP) path over the iBGP path.
10. Prefer the route that can be reached through the closest IGP neighbor (the lowest IGP metric).
11. If the following conditions are all true, insert the route for this path into the IP routing table:
–Both the best route and this route are external.
–Both the best route and this route are from the same neighboring autonomous system.
–The maximum-paths router configuration command is enabled.
12. If multipath is not enabled, prefer the route with the lowest IP address value for the BGP router ID. [The router ID is usually the highest IP address on the router or the loopback (virtual) address, but might be implementation-specific.]

Yeah, that's a lot to remember. But it makes sense as you go through it. And basically you have to really just remember the attributes:

Weight (Largest)
Local Preference (Largest)
AS Path
Origin Code
MED (Lowest)
eBGP over iBGP

These are the things that would be manipulated to make your traffic flow as desired. I've used Local Preference and AS Path manipulation before, so I'm good with this part. YMMV. I used Local Preference with Communities, so I guess that should be next.

BGP Communities are a way of "tagging" or "grouping" (my words) a bunch of routes. If your primary connection is to ISP1 and your secondary connection is to ISP2 - how would you make your traffic to all destinations use the primary and only use the secondary if it's not available? If both ISPs advertise a route to X.X.X.X, you are then relying on them to determine the "best" route based on their advertisements of that route to you. Perhaps ISP2 is closer (shorter AS Path) than ISP1. But you have a large bandwidth connection to ISP1 and a (slightly) smaller bandwidth connection to ISP2 (since it's just the backup). Well, you can use a community on routes coming in and set metrics so that you can determine locally what you want to happen. You can also use communities to determine what you want advertised to which peer. It's a useful optional, transitive, global attribute (remember those types). There are also predefined well-known communities. [Note: some ISPs will strip the community attribute - check this if you're ever configuring BGP for reals.]

The community attribute, like other things, also has an old and new format. The old/default format is NNAA - where N is your number and A is your AS. To use the new format, use the command "ip bgp-community new-format" in global configuration mode. This will put the format to the new AA:NN. And there are also Extended Communities. I think that those may be beyond the scope - other than to know they exist.

And yet, there's still more to BGP (and I'm only scratching the surface here). One little tidbit that I'd like to point out - actually security-related - relates to Bogons and Martians. Yes, that's the actual name of them. Bogons are prefixes that are advertised on the Internet (via BGP) that really shouldn't be there. Bogus prefixes. Martians are "packets from Mars" - ones that shouldn't be on the Internet. When you peer with your ISP, you shouldn't receive a BGP route to 192.168.100.0 /24 from them. That's not really a route on the Internet - it's 1918 Private Address space. Then there are other reserved addresses or unallocated addresses which should not be advertised in the Internet routing table. Well Team Cymru is on the case! They actually keep track of these prefixes as they crop up so you can filter them. It's nice to know someone is helping to clean up the Internet.