« Version 4.1 - 1.5 Routing Protocols Part 2 | Main | Version 4.1 - 1.5 Routing Protocols Part 4 »

Version 4.1 - 1.5 Routing Protocols Part 3

BGP is the only exterior routing protocol of the group. RIP, EIGRP and OSPF are used within a business' area of control. BGP is the protocol that you run between businesses. That's a bit of an oversimplification, but when you configure BGP, you're touching the Internet. Really. This is big stuff and is not to be taken lightly. Since my CCNA days (so very long ago), I always remembered the warnings that you shouldn't use/configure BGP unless you really TOTALLY understood it and knew what you were doing and its ramifications. However, for this exam the finer points are probably not going to be explored. But the core points should be known thoroughly.

Keep in mind that all of section 1 has about 14 or so questions on all of the topics. How many of those will be BGP? And if you could create just 3 questions on BGP (to test someone else), what would they be? It sounds silly, but these are the questions you need to ask yourself. This way you don't get stuck in the weeds and don't just skim the surface and not reach down deep enough for this topic.

BGP is classified as a path-vector protocol, but also sometimes considered a distance-vector protocol. The basic idea is that destinations have an advertised AS path to get there. This is the list of Autonomous Systems that it must traverse to get to the destination. This is not necessarily the shortest number of hops, just the shortest number of different businesses (ISPs). And just like any "rule," there are always exceptions. These exceptions are the basis of all the other "stuff" of the protocol. These things exist so that engineers can manipulate their sent and received advertisements to optimize traffic in and out of the business.

BGP uses TCP as a transport protocol (port 179). There is iBGP (internal BGP) which operates between BGP peers in the same AS and eBGP (external BGP) which operates between AS numbers (which may or may not be a different company). And that's the first thing that I want to review - AS numbers. The 16-bit AS numbers have relatively "recently" been expanded to 32-bit AS numbers. (The RFC for this came out a long time ago, but was implemented in software updates on Cisco devices. It takes a while for new software to become deployed to the point where the information shows up on tests.) If I could pick a question on BGP - it would be on this subject.

Like all other Internet numbering systems, IANA controls the assignment of Autonomous System numbers. These numbers are assigned to the 5 Regional Internet Registries and they further allocate them to businesses (ISPs - which would allocate them further to your business). The 16-bit numbers range from 0 (Reserved) to 65,535 (Reserved). Most of the numbers in between are allocated, but there are special numbers in this space. AS Number 23456 has been reserved as AS_TRANS - to be used by routers using 32-bit ASNs to speak to routers using 16-bit ASNs. RFC 6996 covers the AS Numbers reserved for Private Use (just like IPv4's RFC 1918).

IANA has reserved, for Private Use, a contiguous block of 1023 Autonomous System numbers from the "16-bit Autonomous System Numbers" registry, namely 64512 - 65534 inclusive.
IANA has also reserved, for Private Use, a contiguous block of 94,967,295 Autonomous System numbers from the "32-bit Autonomous System Numbers" registry, namely 4200000000 - 4294967294 inclusive.

The private numbers most commonly used are in the 65000 area. You should recognize 65000, 65100, 65101 and 65002 as private AS numbers. You may not get a direct question on this, but knowing this information may help eliminate one or two of the multiple choices you might face on a question.

The 32-bit ASNs are commonly seen in the form of "asdot" notation. This is where you have two 16-bit AS numbers separated with a dot. Cisco has a White Paper on ASPLAIN and ASDOT notation. It's really worth reading. [It may affect your AS_PATH filters.] The RFC's private AS space above is listed in ASPLAIN notation. Taking their example of AS 65546 -> becomes AS 1.10 (1*65535 + 10 = 65546). All of the Cisco exams I've seen have always used very obvious numbers in their questions. As long as you know that 65546 would be 1.10 instead of 65535.10 or 10.65535, you should be fine. The numbers they use are normally obvious in some way - I've never had to resort to long and complex calculations to answer a question. ASPLAIN is the default notation and the command " bgp asnotation dot " under the bgp configuration will configure ASDOT notation.

While on ASNs, let's consider BGP Confederations. This is a method to divide a single AS into multiple internal sub-AS's yet still advertise a single AS to external peers. This is to reduce the number of connections needed for the iBGP mesh. The confederation configuration is simple.

bgp confederation identifier as-number (this should be the ASN that you want the external world to see)
bgp confederation peers as-number [as-number]

Here's an example configuration snippet:

router bgp 6002
 bgp confederation identifier 60000
 bgp confederation peers 6001 6003
 neighbor 170.70.70.1 remote-as 6002
 neighbor 171.69.232.57 remote-as 6001
 neighbor 171.69.232.56 remote-as 6003
 neighbor 199.99.99.2 remote-as 700

If you can look at this and identify the AS this confederation is seen as, the peers, and which routers are running iBGP and eBGP with this router, you're good on this.

Remember that BGP was made for routing the Internet. The entire Internet. It's always going to be about scale and (local) optimizations. BGP requires that iBGP speakers are fully meshed. Confederations are one way to deal with making that scale. Route Reflectors are another way to reduce the amount of connections needed for a full mesh. The full mesh is required so that everybody gets "the memo" - but you also want to make sure that no routing loops occur (the point of a routing protocol). So in a real full mesh, routes from external neighbors are passed on to iBGP neighbors, but routes learned from iBGP are not - to prevent a loop. The route reflector configuration allows a partially meshed system where iBGP information can be passed to route-reflector clients. This way you don't have to have a full mesh and you avoid loops. Think about various examples of groups of routers which are partially meshed. Which router in that group would you configure as a route-reflector? The Cisco Documentation link gives a couple of good examples.

Here is another main point about route-reflectors:


When the route reflector receives an advertised route, depending on the neighbor, it takes the following actions:
•A route from an external BGP speaker is advertised to all clients and nonclient peers.
•A route from a nonclient peer is advertised to all clients.
•A route from a client is advertised to all clients and nonclient peers. Hence, the clients need not be fully meshed.

To set this up, you just configure the clients on the route reflector. (No client configuration needed) If there is more than one route reflector in a cluster, you must configure the cluster-id.

You may want to take a look at peer-groups if you're not familiar with them. But I don't see how that would end up on the Security exam. It's more of a R/S question.

And we have barely scratched the surface of BGP. More in the next part.

Sections

Powered by
Movable Type 3.2