What Certification Should You Pursue After The CCNA ?

Once you've got your CCNA, you're ready to move on to the next level, the Professional certifications. For years, Cisco had one Professional certification, the Cisco Certified Network Professional (CCNP) certification. Over time, Cisco has expanded this level of certifications to include the Cisco Certified Security Professional (CCSP) and Cisco Certified Voice Professional (CCVP).

With security and voice being the two most rapidly expanding areas of today's networks, some new CCNAs consider going after the CCSP or CCVP without first adding the CCNP to their resume.

While it's temping to hurry up and get a Cisco security or voice certification, the best thing you can do for your networking career is achieve your CCNP certification first, then decide on the CCVP or CCSP.

Why? Because the CCNA is just the tip of a very large iceberg when it comes to routing and switching. It's a very important accomplishment, and the CCNA is indeed the foundation of your networking career, but you need to add on to that level of understanding routing and switching before moving on to more specialized areas.

Two examples are OSPF and BGP. You learn about the theory of OSPF and some basic and intermediate configurations of that protocol in your CCNA studies, but the knowledge you acquire of OSPF in your CCNP studies is invaluable. As for BGP, there is no BGP in the CCNA curriculum, but it is a great idea to have some BGP knowledge in today's networks. It's also good for your career.

I know it is a huge temptation to go after the security and voice certifications while not paying attention to the CCNP. Do yourself a huge favor and add the tremendous amount of routing and switching knowledge needed for the CCNP to your knowledgebase, and you can then move on to the CCSP or CCVP. Even better, you'll be better prepared to climb the biggest certification mountain around - the CCIE!

Cisco CCNP Certification: Using The BGP Command “Update-Source”

When you start preparing for your CCNP exam, particularly the BSCI exam, you're introduced to Border Gateway Protocol (BGP) configurations. BGP is unlike any protocol you learned during your CCNA studies, and even the similarities are a little bit different!

BGP forms neighbor relationships, much like EIGRP and OSPF do. The interesting thing with BGP is that potential neighbors, or "peers", do not need to be directly connected and can use their loopback interfaces to form the peer relationships.

It may well be to your advantage to use loopbacks to form peer relationships rather than the actual interface facing the potential neighbor. This can be done because BGP uses static neighbor statements rather than any kind of dynamic neighbor discovery process.

Consider a router that has two paths to a BGP speaker. The interfaces are numbered like this:

Router1: Serial0, 172.1.1.1 /24, Serial2, 179.1.1.1 /24, loopback0, 1.1.1.1 /32.

Router2: Serial0, 172.1.1.2/24, Serial2 179.1.1.2/24, loopback0, 2.2.2.2 /32.

We could configure Router1 like this:

router bgp 200

neighbor 172.1.1.2 remote-as 200

In this case, BGP would automatically use 172.1.1.1 as the source for the TCP connection that has to be set up with the neighbor before updates can be exchanged; this address is known as the best local address. However, if the remote peer's serial0 interface is shut down or goes down for another reason, the peer relationship would be lost even though Router2 is still available.

Instead of using one of the physical interfaces, we can use the loopbacks on each router to establish the TCP-based peer connection. The configurations would look like this:

Router1:

router bgp 200

neighbor 2.2.2.2 remote-as 200

neighbor 2.2.2.2 update-source loopback0

Router2:

router bgp 200

neighbor 1.1.1.1 remote-as 200

neighbor 1.1.1.1 update-source loopback0

In this case, losing one of the physical connections does not necessarily mean the BGP peering is lost; as long as the routers have a valid path to each other's loopback addresses, the BGP peer relationship will stay in place. And better yet, we avoid the dreaded “single point of failure

Cisco CCNP Certification: The BGP Weight Attribute

When you're studying for the CCNP certification, especially the BSCI exam, you must gain a solid understanding of BGP. BGP isn't just one of the biggest topics on the BSCI exam, it's one of the largest. BGP has a great many details that must be mastered for BSCI success, and those of you with one eye on the CCIE must learn the fundamentals of BGP now in order to build on those fundamentals at a later time.

Path attributes are a unique feature of BGP. With interior gateway protocols such as OSPF and EIGRP, administrative distance is used as a tiebreaker when two routes to the same destination had different next-hop IP addresses but the same prefix length. BGP uses path attributes to make this choice.

The first attribute considered by BGP is weight. Weight is a Cisco-proprietary BGP attribute, so if you're working in a multivendor environment you should work with another attribute to influence path selection.

The weight attribute is significant only to the router on which it is changed. If you set a higher weight for a particular route in order to give it preference (a higher weight is preferred over a lower one), that weight is not advertised to other routers.

BGP uses categories such as "transitive", "non-transitive", "mandatory", and "optional" to classify attributes. Since weight is a locally significant Cisco-proprietary attribute, it does not all into any of these categories.

The weight can be changed on a single route via a route-map, or it can be set for a different weight for all routes received from a given neighbor. To change the weight for all incoming routes, use the "weight" option with the neighbor command after forming the BGP peer relationships.

R2(config)#router bgp 100

R2(config-router)#neighbor 100.1.1.1 remote-as 10

R2(config-router)#neighbor 100.1.1.1 weight 200

Learning all of the BGP attributes, as well as when to use them, can seem an overwhelming task when you first start studying for your BSCI and CCNP exams. Break this task down into small parts, learn one attribute at a time, and soon you'll have the BGP attributes mastered.

Cisco CCNP Certification / BSCI Exam Tutorial: An Introduction To BGP

When you're studying for the BSCI exam on the way to earning your CCNP certification, it's safe to say that BGP is like nothing you’ve studied to this point. BGP is an external routing protocol used primarily by Internet Service Providers (ISPs). Unless you work for an ISP today or in the future, you may have little or no prior exposure to BGP. Understanding BGP is a great addition to your skill set – and you have to know the basics well to pass the BSCI exam.

Note that I said “the basics”. BGP is a very complex protocol, and when you pursue your CCIE, you’ll see what I’m talking about. As with all things Cisco, though, when broken down into smaller pieces, BGP becomes quite understandable. You will need to know the basics of BGP as presented in this chapter to pass your BSCI exam – so let’s get started.

BGP Defined:

“An Internet protocol that enables groups of routers (called autonomous systems) to share routing information so that efficient, loop-free routes can be established. BGP is commonly used within and between Internet Service Providers (ISPs).”

There are a couple of terms in there that apply to the protocols you’ve mastered so far in your studies. The term “autonomous system” applies to IGRP and EIGRP as well as BGP; you’ll be indicating a BGP AS in your configurations just as you did with IGRP and EIGRP. And we’re always looking for efficient, loop-free routes, right? As it did with IGRP and EIGRP, "autonomous system" simply refers to a group of routers that is managed by a single administrative body. An autonomous system will use an Interior Gateway Protocol (IGP) such as OSPF or EIGRP to route packets inside the AS; outside the AS, an Exterior Gateway Protocol (EGP) such as BGP will be used.

BGP shares some characteristics with some routing protocols you’ve already studied. BGP supports VLSM, summarization, and CIDR. Like EIGRP, BGP will send full updates when two routers initially become neighbors and will send only partial updates after that. BGP does create and maintain neighbor relationships before exchanging routes, and keepalives are sent to keep this relationship alive.

BGP has some major differences from the IGPs we’ve studied to this point. You’ll hear BGP referred to as a path-vector protocol. As opposed to distance-vector protocols that exchange relatively simple information about available routes, BGP routers will exchange extensive information about networks to allow the routers to make more intelligent routing decisions. This additional BGP path information comes in the form of attributes, and these path attributes are contained in the updates sent by BGP routers. Attributes themselves are broken up into two classes, well-known and optional.

BGP also keeps a routing table separate from the IP routing table.
We'll take a look at BGP attributes in future BSCI tutorials. In the meantime, keep studying!

Cisco CCNP / BSCI Tutorial: The BGP Attribute NEXT_HOP

When you're studying for the BSCI exam on the way to earning your CCNP certification, you've got to master the use of BGP attributes. These attributes allow you to manipulate the path or paths that BGP will use to reach a given destination when multiple paths to that destination exist.

In this free BGP tutorial, we're going to take a look at the NEXT_HOP attribute. You may be thinking "hey, how complicated can this attribute be?" It's not very complicated at all, but this being Cisco, there's got to be at least one unusual detail about it, right?

The NEXT_HOP attribute is simple enough - this attribute indicates the next-hop IP address that should be taken to reach a destination. In the following example, R1 is a hub router and R2 and R3 are spokes. All three routers are in BGP AS 100, with R1 having a peer relationship with both R2 and R3. There is no BGP peering between R2 and R3.

R3 is advertising the network 33.3.0.0 /24 via BGP, and the value of the next-hop attribute on R1 is the IP address on R3 that is used in the peer relationship, 172.12.123.3.

The issue with the next-hop attribute comes in when the route is advertised to BGP peers. If R3 were in a separate AS from R1 and R2, R1 would then advertise the route to R2 with the next-hop attribute set to 172.12.123.3. When a BGP speaker advertises a route to iBGP peers that was originally learned from an eBGP peer, the next-hop value is retained.

Here, all three routers are in AS 100. What will the next-hop attribute be set to when R1 advertises the route to its iBGP neighbor R2?

R2#show ip bgp

< no output >

There will be no next-hop attribute for the route on R2, because the route will not appear on R2. By default, a BGP speaker will not advertise a route to iBGP neighbors if the route was first learned from another iBGP neighbor.

Luckily for us, there are several ways around this rule. The most common is the use of route reflectors, and we'll look at RRs in a future free BGP tutorial.

Cisco CCNP / BSCI Exam Tutorial: The BGP Attribute MED

Your BSCI exam and CCNP certification success depend on mastering BGP, and a big part of that is knowing how and when to use the many BGP attributes. And for those of you with an eye on the CCIE, believe me - you've got to know BGP attributes like the back of your hand. One such BGP attribute is the Multi-Exit Discriminator, or MED.

The MED attribute is sent from a router or routers in one AS to another AS to indicate what path the remote AS should use to send data to the local AS.

That sounds a little confusing on paper, so let's walk through an example. R1 is in AS 1, and R2, R3, and R4 are in AS 234. R4 is advertising a loopback into BGP, and R1 has two possible next-hops to get to that loopback - R2 (172.12.123.2) and R3 (172.12.123.3). Let's see which of the two paths R1 is using.

R1#show ip bgp 4.4.4.4

BGP routing table entry for 4.4.4.4/32, version 8

Paths: (2 available, best #2, table Default-IP-Routing-Table)

Flag: 0x208

Advertised to non peer-group peers:

172.12.123.3

234

172.12.123.3 from 172.12.123.3 (3.3.3.3)

Origin IGP, localpref 100, valid, external

234

172.12.123.2 from 172.12.123.2 (2.2.2.2)

Origin IGP, localpref 100, valid, external, best

R1 is using 172.12.123.2 as the next-hop to enter AS 234. If all values are left at their default, we could have 100 routes being advertised from AS 234 to AS 1 and the next-hop would remain the same.

We can configure R2 and R3 to send different MED values to R1, and the router sending the lowest MED would be the preferred next-hop. (The MED is a metric, and the lowest metric is always preferred.) We'll configure the MED attribute on both R2 and R3, sending a MED of 200 from R2 and 100 from R3.

R2(config)#route-map SET_MED_200 permit 10

R2(config-route-map)#set metric 200

R2(config-route-map)#router bgp 234

R2(config-router)#neighbor 172.12.123.1 route-map SET_MED_200 out

R3(config)#route-map SET_MED_100 permit 10

R3(config-route-map)#set metric 100

R3(config-route-map)#router bgp 234

R3(config-router)#neighbor 172.12.123.1 route-map SET_MED_100 out

After clearing the BGP table on R1, R1 will still see both next-hop addresses and will still consider both to be valid, but the path through R3 will be selected due to its lower metric.

Just keep in mind that the MED is actually a metric, and lower metrics are more desirable in path selection. That will put you one step closer to passing the BSCI and earning your CCNP Certification!

Cisco CCNP / BSCI Exam Tutorial: Introduction To Policy Routing

Policy routing is a major topic on your BSCI exam, and you'll find quite a bit of policy routing going on in today's production networks. But what exactly is policy routing?

Policy-based routing, generally referred to as "policy routing", is the use of route maps to determine the path a packet will take to get to its final destination. As you progress through your CCNP studies and go on to the CCIE (or to a Cisco Quality Of Service certification), you'll find that traffic can be "marked" by policy routing in order to give different levels of service to various classes of traffic. (This is done by marking the traffic and placing the different classes of traffic in different queues in the router, allowing the administrator to give some traffic higher priority for transmission.)

There are some basic policy routing rules you should know:

Policy routing doesn't affect the destination of the packet, but does affect the path that is taken to get there.

Policy routing can forward traffic based on the source IP address or the destination IP address (with the use of an extended ACL).

Policy routing can be configured at the interface level, or globally.


Applying policy routing on an interface affects only packets arriving on that interface:

R2(config)#int s0

R2(config-if)#ip policy route-map CHANGE_NEXT_HOP

Applying the policy globally applies the route map to packets generated on the router, not on all packets received on all interfaces.

Whether you're running policy routing at the interface level, on packets created locally, or both, always run the command show ip policy to make sure you've got the right route maps on the proper interfaces.

R2#show ip policy

Interface Route map

local CHANGE_NEXT_HOP

Serial0 CHANGE_NEXT_HOP

And here's the big rule to remember....

If a packet doesn't match any of the specific criteria in a route map, or does match a line that has an explicit deny statement, the data is sent to the routing process and will be processed normally. If you don't want to route packets that do not meet any route map criteria, the set command must be used to send those packets to the null0 interface. This set command should be the final set command in the route map.

There are four possibilities for an incoming packet when route maps are in use. The following example illustrates all of them.

R2(config)#access-list 29 permit host 20.1.1.1

R2(config)#access-list 30 permit host 20.2.2.2

R2(config)#access-list 31 permit host 20.3.3.3

R2(config)#access-list 32 permit host 20.4.4.4

R2(config)#route-map EXAMPLE permit 10

R2(config-route-map)#match ip address 29

R2(config-route-map)#set ip next-hop 40.1.1.1


R2(config-route-map)#route-map EXAMPLE permit 20

R2(config-route-map)#match ip address 30

Assuming the route map has been applied to the router's ethernet0 interface, a packet sourced from 20.1.1.1 would meet the first line of the route map and have its next-hop IP address set to 40.1.1.1.

A packet sourced from 20.2.2.2 would match the next permit statement (sequence number 20). Since there is no action listed, this packet would return to the routing engine to undergo the normal routing procedure. All traffic that did not match these two addresses would also be routed normally - there would be no action taken by the route map.

Perhaps we want to specifically block traffic sourced from 20.3.3.3 or 20.4.4.4. We can use multiple match statements in one single route map, and have packets matching those two addresses sent to the bit bucket - the interface null0.

R2(config)#route-map EXAMPLE permit 30

R2(config-route-map)#match ip address 31

R2(config-route-map)#match ip address 32

R2(config-route-map)#set ?

as-path Prepend string for a BGP AS-path attribute

automatic-tag Automatically compute TAG value

comm-list set BGP community list (for deletion)

community BGP community attribute

dampening Set BGP route flap dampening parameters

default Set default information

extcommunity BGP extended community attribute

interface Output interface

ip IP specific information

level Where to import route

local-preference BGP local preference path attribute

metric Metric value for destination routing protocol

metric-type Type of metric for destination routing protocol

origin BGP origin code

tag Tag value for destination routing protocol

weight BGP weight for routing table

R2(config-route-map)#set interface null0

Any traffic matching ACLs 31 or 32 will be sent to null0, resulting in its being discarded by the router. Any traffic that didn't match any of the route map statements will be returned to the routing engine for normal processing.

Knowing policy routing and how to apply it are essential skills for passing the BSCI exam, earning your CCNP, and becoming more valuable in today's job market. Get some hands-on practice in a CCNA / CCNP home lab or rack rental to go along with learning the theory, and you'll be writing and applying policy routing in no time at all.

Cisco CCNP / BSCI Exam Tutorial: Filtering BGP Updates With Prefix

A major part of your BSCI and CCNP exam success is mastering BGP, and that includes filtering BGP routing updates. In this tutorial, we'll take a look at how to filter BGP updates with prefix lists.

R4 is advertising three networks via BGP. The downstream router R3 sees these routes and places them into its BGP table as shown below. R3 has two downstream BGP peers, R1 and R2, and is advertising itself as the next-hop IP address for all BGP routes sent to those two routers.

R4(config)#router bgp 4

R4(config-router)#network 21.0.0.0 mask 255.0.0.0

R4(config-router)#network 22.0.0.0 mask 255.0.0.0

R4(config-router)#network 23.0.0.0 mask 255.0.0.0


R3#show ip bgp

BGP table version is 4, local router ID is 3.3.3.3

Status codes: s suppressed, d damped, h history, * valid, > best, i –
Internal

Origin codes: i - IGP, e - EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path

*> 21.0.0.0 10.2.2.4 0 0 4 I

*> 22.0.0.0 10.2.2.4 0 0 4 I

*> 23.0.0.0 10.2.2.4 0 0 4 I

R3(config)#router bgp 123

R3(config-router)#neighbor 172.12.123.1 next-hop-self

R3(config-router)#neighbor 172.12.123.2 next-hop-self

In turn, both R1 and R2 have these three routes in their respective BGP tables.

R2#show ip bgp

BGP table version is 4, local router ID is 2.2.2.2

Status codes: s suppressed, d damped, h history, * valid, > best, i –
Internal

Origin codes: i - IGP, e - EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path

*>i21.0.0.0 172.12.123.3 0 100 0 4 I

*>i22.0.0.0 172.12.123.3 0 100 0 4 I

*>i23.0.0.0 172.12.123.3 0 100 0 4 I


R1#show ip bgp

BGP table version is 4, local router ID is 19.1.1.1

Status codes: s suppressed, d damped, h history, * valid, > best, i –
Internal

Origin codes: i - IGP, e - EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path

*>i21.0.0.0 172.12.123.3 0 100 0 4 I

*>i22.0.0.0 172.12.123.3 0 100 0 4 I

*>i23.0.0.0 172.12.123.3 0 100 0 4 I

If we wanted R3 to receive all three of these routes from R4 but not advertise all of them to R2 and R1, we've got a couple of options on how to block these routes. Cisco's recommendation is the use of prefix-lists, and once you get used to the syntax (which you should do before taking and passing the BSCI), you'll see they are actually easier to use than access-lists.

In this case, we're going to configure R3 to send only the route to 21.0.0.0 to R1 and 23.0.0.0 to R2. However, we do want these two routers to get any future routes that R4 advertises into BGP.

Since R1 and R2 will learn about these routes from an iBGP neighbor, they will not advertise the routes to each other.

On R3, we'll write a prefix-list that denies 22.0.0.0/8 and 23.0.0.0/8, but permits all other routes. After applying the prefix list as shown, R1 sees only the 21.0.0.0 /8 route.

R3(config)#ip prefix-list FILTER_R1 deny 22.0.0.0/8

R3(config)#ip prefix-list FILTER_R1 deny 23.0.0.0/8

R3(config)#ip prefix-list FILTER_R1 permit 0.0.0.0/0 le 32

R3(config)#router bgp 123

R3(config-router)#neighbor 172.12.123.1 prefix-list FILTER_R1 out

R3#clear ip bgp * soft

R1#show ip bgp

BGP table version is 6, local router ID is 19.1.1.1

Status codes: s suppressed, d damped, h history, * valid, > best, i –
Internal

Origin codes: i - IGP, e - EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path

*>i21.0.0.0 172.12.123.3 0 100 0 4 I

The paths to 22.0.0.0/8 and 23.0.0.0/8 have been successfully filtered.

We'll do the same for R2, except the route not being expressly blocked is 23.0.0.0/8. The line "ip prefix-list permit 0.0.0.0/0 le 32" is the prefix list equivalent of a "permit any" statement in an ACL.

R3(config)#ip prefix-list FILTER_R2 deny 21.0.0.0/8

R3(config)#ip prefix-list FILTER_R2 deny 22.0.0.0/8

R3(config)#ip prefix-list FILTER_R2 permit 0.0.0.0/0 le 32

R3(config)#router bgp 123

R3(config-router)#neighbor 172.12.123.2 prefix-list FILTER_R2 out

R3#clear ip bgp * soft

R2#show ip bgp

BGP table version is 6, local router ID is 2.2.2.2

Status codes: s suppressed, d damped, h history, * valid, > best, i –
Internal

Origin codes: i - IGP, e - EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path

*>i23.0.0.0 172.12.123.3 0 100 0 4 I

The paths to 21.0.0.0/8 and 22.0.0.0/8 have been successfully filtered.

To see the prefix lists configured on a route as well as the order of the statements in each list, run show ip prefix-list.

R3#show ip prefix-list

ip prefix-list FILTER_R1: 3 entries

seq 5 deny 22.0.0.0/8

seq 10 deny 23.0.0.0/8

seq 15 permit 0.0.0.0/0 le 32

ip prefix-list FILTER_R2: 3 entries

seq 5 deny 21.0.0.0/8

seq 10 deny 22.0.0.0/8

seq 15 permit 0.0.0.0/0 le 32

Get some hands-on practice with prefix lists and you'll quickly master them. Prefix lists are an important part of working with BGP in the exam room and production networks, so it's vital that you are comfortable working with them.

Cisco CCNP / BSCI Exam Tutorial: BGP Adjacency States

To pass the BSCI exam, earn your CCNP certification, and become an outstanding networker, you've got to master the many details of BGP - and trust me, there are a lot of details to master! Before you get into the more advanced features of BGP, you should have the fundamentals down cold, and one of those fundamentals is knowing the BGP adjacency states. This will allow you to successfully analyze and troubleshoot BGP peer relationships.


In the following example, a BGP peering is being created between R1 and R3.
R1(config-router)#neighbor 172.12.123.3 remote-as 200

BGP speakers do not have to be in the same AS to become peers. To verify that the remote BGP speaker has become a peer, run show ip bgp neighbor.


R1#show ip bgp neighbor

BGP neighbor is 172.12.123.3, remote AS 200, external link

BGP version 4, remote router ID 0.0.0.0

BGP state = Active

Last read 00:01:39, hold time is 180, keepalive interval is 60 seconds

Received 0 messages, 0 notifications, 0 in queue

Sent 0 messages, 0 notifications, 0 in queue

Route refresh request: received 0, sent 0

Default minimum time between advertisement runs is 30 seconds

The output here can be a little misleading the first time you read it. The first highlighted line shows 172.12.123.3 is a BGP neighbor, is located in AS 200, and is an external link, indicating that the neighbor is in another AS entirely. The second highlighted line shows the BGP state as Active. This sounds great, but it actually means that a BGP peer connection does not yet exist with the prospective neighbor. Before we continue with this example, let’s look at the different BGP states:

Idle is the initial state of a BGP connection. The BGP speaker is waiting for a start event, generally either the establishment of a TCP connection or the re-establishment of a previous connection. Once the connection is established, BGP moves to the next state.

Connect is the next state. If the TCP connection completes, BGP will move to the OpenSent stage if the connection does not complete, BGP goes to Active.

Active indicates that the BGP speaker is continuing to create a peer relationship with the remote router. If this is successful, the BGP state goes to OpenSent. You’ll occasionally see a BGP connection flap between Active and Connect. This indicates an issue with the physical cable itself, or with the configuration.

OpenSent indicates that the BGP speaker has received an Open message from the peer. BGP will determine whether the peer is in the same AS (iBGP) or a different AS (eBGP) in this state.

In OpenConfirm state, the BGP speaker is waiting for a keepalive message. If one is received, the state moves to Established, and the neighbor relationship is complete. It is in the Established state that update packets are actually exchanged.

So even though the show ip bgp neighbor output indicated that this is an Active neighbor relationship, that’s not as good as it sounds. Of course, the reason the peer relationship hasn’t been established is that we haven’t configured R3 yet!


R3(config)#router bgp 200

R3(config-router)#neighbor 172.12.123.1 remote-as 100

Verify the peer establishment with show ip bgp neighbor:

R3#show ip bgp neighbor

BGP neighbor is 172.12.123.1, remote AS 100, external link

BGP version 4, remote router ID 172.12.123.1

BGP state = Established, up for 00:01:18

Last read 00:00:17, hold time is 180, keepalive interval is 60 seconds

Neighbor capabilities:

Route refresh: advertised and received(old & new)

Address family IPv4 Unicast: advertised and received

Received 5 messages, 0 notifications, 0 in queue

Sent 5 messages, 0 notifications, 0 in queue

Route refresh request: received 0, sent 0

Default minimum time between advertisement runs is 30 seconds

Local host: 172.12.123.3, Local port: 179 (BGP uses TCP Port 179)

Foreign host: 172.12.123.1, Foreign port: 11007

The peer relationship between R1 and R3 has been established!

Cisco CCNP / BSCI Certification: Troubleshooting Route Redistribution, Part I

If there's one CCNP / BSCI topic that looks so easy but can lead to a real headache, it's route redistribution. I'm not even talking about the routing loops and suboptimal routing that can result when route redistribution is done without proper planning - I'm talking about the basic commands themselves. Leaving out one single command option, or forgetting what else needs to be redistributed when redistributing dynamically discovered routes, can leave you with a routing table that looks complete but does not result in full IP connectivity.

In this free CCNP / BSCI tutorial series, we'll take a look at three common errors in route redistribution configurations, and how to fix them. We'll use three routers, R1, R3, and R5. R1 and R5 are in a RIPv2 domain and R1 and R3 are in an OSPF domain. R1 will be performing two-way route redistribution.

R5 is advertising its loopback, 5.5.5.5/24, into the RIPv2 domain. R1 sees this route in its RIP routing table:

R1#show ip route rip

5.0.0.0/24 is subnetted, 1 subnets

R 5.5.5.0 [120/1] via 100.1.1.5, 00:00:01, Ethernet0

For R3 to see this route, route redistribution must be configured on R1. We'll use the redistribute rip command to do so.

R1(config)#router ospf 1

R1(config-router)#redistribute rip

% Only classful networks will be redistributed

The router immediately gives us a message that "only classful networks will be redistributed". What does this mean? Let's go to R3 and see if that router is receiving this route.

R3#show ip route ospf

< no output >

When we get no result from a show command, that means there's nothing to show. The only routes that will be successfully redistributed with the current configuration on R1 are classful networks, and 5.5.5.0/24 is a subnet.

To further illustrate the point, a classful network has been added to R5. This network is 16.0.0.0 /8, and is now being advertised by RIP. R1 sees this network as classful...

R1#show ip route rip

R 16.0.0.0/8 [120/1] via 100.1.1.5, 00:00:00, Ethernet0

5.0.0.0/24 is subnetted, 1 subnets

R 5.5.5.0 [120/1] via 100.1.1.5, 00:00:00, Ethernet0

... and R3 is receiving the route through redistribution.

R3#show ip route ospf

O E2 16.0.0.0/8 [110/20] via 172.12.123.1, 00:00:08, Serial0.31

To redistribute both classful and classless networks, the option "subnets" must be added to the redistribute command on R1.

R1(config)#router ospf 1

R1(config-router)#no redistribute rip

R1(config-router)#redistribute rip subnets

R3 will now see both the classful and classless networks being redistributed into OSPF. (100.1.1.0 is the network connecting R1 and R5.)

R3#show ip route ospf

O E2 16.0.0.0/8 [110/20] via 172.12.123.1, 00:00:20, Serial0.31

100.0.0.0/24 is subnetted, 1 subnets

O E2 100.1.1.0 [110/20] via 172.12.123.1, 00:00:20, Serial0.31

5.0.0.0/24 is subnetted, 1 subnets

O E2 5.5.5.0 [110/20] via 172.12.123.1, 00:00:20, Serial0.31

This is one of the most common errors made during route redistribution, but now you know what to look out for! In the next part of this free CCNP / BSCI tutorial, we'll take a look at another such error.

Cisco CCNP / BSCI Certification: The Local Preference BGP Attribute

When studying for your BSCI exam for the CCNP, you get your first taste of BGP. One of the major differences between BGP and the other protocols you've studied to date is that BGP uses attributes to describe paths, and to influence the selection of one path over the other.

In this free tutorial, we're going to take a look at the Local Preference attribute and compare it to the Cisco-proprietary BGP attribute "weight".

The Local Preference (LOCAL_PREF) attribute is used to influence how traffic will flow from one Autonomous System (AS) to another when multiple paths exist. For example, if AS 100 has two different paths to a destination network in AS 200, the LOCAL_PREF attribute can be used to influence the path selection.

The major difference between the Weight and LOCAL_PREF attributes is that when the LOCAL_PREF attribute is changed, that change is reflected throughout the AS. The new LOCAL_PREF value will be advertised to all other routers in the AS, as compared to the Weight attribute, which is locally significant only. If you change the Weight for a path on one router in an AS, the other routers in the AS will not learn of the change.

A route-map can be used to change a local preference value. For example, if you want to change the local preference value to 200 for the path advertisement 10.2.2.0/24 coming in from neighbor 10.1.1.1, there are three steps involved. First, write an ACL matching the remote network you want to change the local preference for.

R1(config)#access-list 5 permit 10.2.2.0 0.0.0.255

Second, write a route-map setting the local preference to 200. This will double the default value of 100, and the path with the highest local preference will be the preferred path.

R1(config)#route-map PREFER_PATH permit 10

R1(config-route-map)#match ip address 5

R1(config-route-map)#set local-pref 200

Finally, apply the route-map to routes that are being received from 10.1.1.1.

R1(config)#router bgp 100

R1(config-router)#network 10.1.1.1 route-map PREFER_PATH in

R1 will then advertise this new local preference value to all other routers in AS 100 - all of its iBGP neighbors.

Cisco CCNP / BSCI Certification: The BGP Attribute “MED”

When you're preparing to pass the BSCI exam and earn your CCNP certification, one of the biggest challenges is learning BGP. BGP is totally different from any protocol you learned to earn your CCNA certification, and one of the differences is that BGP uses path attributes to favor one path over another when multiple paths to or from a destination exist.

Notice I said "to or from". In earlier free BGP tutorials, I discussed the BGP attributes "weight" and "local preference". These attributes are used to favor one path to a destination over another; for example, if BGP AS 100 has two paths to a destination in AS 200, these two attributes can be set in AS 100 to favor one path over another. But what if AS 100 wants to inform the routers in AS 200 as to which path it should use to reach a given destination in AS 100?

That's where the BGP attribute "Multi-Exit Discriminator", or MED, comes in. The MED value can be set in AS 100 to tell AS 200 which path it should use to reach a given network in AS 100.

As with many BGP attributes, the MED can be set with a route-map. What you need to watch is that there is no "set med" value in route maps. To change the MED of a path, you need to change the metric of that path. Let's say that there are two entry paths for AS 200 to use to reach destinations in AS 100. You want AS 200 to use the 100.1.1.0/24 path over the 100.2.2.0/24 path. First, identify the two paths with two separate ACLs.

R1(config)#access-list 22 permit 100.1.1.0 0.0.0.255

R1(config)#access-list 23 permit 100.2.2.0 0.0.0.255

Next, write a route-map that assigns a lower metric to the more-desirable path.

R1(config)#route-map PREFER_PATH permit 10

R1(config-route-map)#match ip address 22

R1(config-route-map)#set metric 100

R1(config-route-map)#route-map PREFER_PATH permit 20

R1(config-route-map)#match ip address 23

R1(config-route-map)#set metric 250

Finally, apply the route-map to the neighbor or neighbors.

R1(config-route-map)#router bgp 100

R1(config-router)#neighbor 22.2.2.2 route-map PREFER_PATH out

The key points to keep in mind is that while many BGP attributes prefer a higher value, the MED is basically an external metric - and a lower metric is preferred, just as with the protocols you've already studied to earn your CCNA certification.

Cisco CCNP / BSCI Certification: BGP Route Reflector Tutorial

When you're studying for your BSCI exam and CCNP certification, you quickly realize that BGP is a whole new world from anything you've previously studies. One topic that sometimes confuses CCNP candidates is when a BGP route reflector needs to be configured.

In the following example, the routers R1, R2, and R3 are all in BGP AS 100. This is not a full mesh, however. There are peer relationships between R1-R2 and R1-R3, but not between R2 and R3. R3 is advertising network 3.3.3.0/24 via BGP, and the route is seen on R1. R1's iBGP neighbor, R2 does not see the route.

A basic rule of BGP is that a BGP speaker cannot advertise a route to an iBGP neighbor if that route was learned from another iBGP neighbor. Configuring R1 as a route reflector will allow us to circumvent this rule. The entire route reflector process is transparent to the clients, and no configuration is necessary on those clients. We'll configure R1 as a route reflector for both R2 and R3.

R1(config)#router bgp 100

R1(config-router)#neighbor 172.12.123.2 route-reflector-client

3d18h: %BGP-5-ADJCHANGE: neighbor 172.12.123.2 Down RR client config change

R1(config-router)#neighbor 172.12.123.3 route-reflector-client

3d18h: %BGP-5-ADJCHANGE: neighbor 172.12.123.3 Down RR client config change

The BGP adjacencies do come down when this configuration is added, so this isn't something you want to do during a peak traffic time.

Once the adjacencies come back up, R2 will have the route to 3.3.3.0/24.

There are other possible solutions to this iBGP limitation, such as configuring BGP confederations. Those solutions are generally used on larger BGP deployments and with other concerns in mind, though, and configuring route reflectors serves this purpose just as well.

Cisco CCNA Certification: The Path To Take After Earning The CCNA

Once you earn your CCNA certification, you've got quite a few exciting choices ahead of you! The majority of CCNAs go on to pursue another Cisco certification, and this is a wise decision. The more you know, the more valuable you are in today's IT market.

A question I'm often asked by new CCNAs is "Which certification should I go after next?" Often, these new CCNAs have their eye on the Cisco Certified Security Professional (CCSP) certification. While adding a security certification to your resume is an excellent idea, I strongly recommend that new CCNAs acquire their Cisco Certified Network Professional (CCNP) certification before pursuing their security certifications. The CCNP requires you to pass three or four exams (depending on the path you choose) that will demand a further mastery of some subjects you studies to earn your CCNA as well as several important topics that you haven’t seen yet.

The CCNP builds on the foundation of networking knowledge you built when you earned your CCNA, and your CCNP study will add greatly to your skills and resume. There are some common technologies that you'll see in many networks - BGP and route redistribution among them - that you don't learn about in your CCNA studies. By pursuing your CCNP, you'll also learn much more about OSPF, switching, and refine your troubleshooting skills. These are skills that will pay off in your current job as well as any future job hunting you do.

Cisco CCNA / CCNP Certification: Introduction To BGP Attributes

BGP is one of the most complex topics you'll study when pursuing your CCNP, if not the most complex. I know from personal experience that when I was earning my CCNP, BGP is the topic that gave me the most trouble at first. One thing I keep reminding today's CCNP candidates about, though, is that no Cisco technology is impossible to understand if you just break it down and understand the basics before you start trying to understand the more complex configurations.

BGP attributes are one such topic. You've got well-known mandatory, well-known discretionary, transitive, and non-transitive. Then you've got each individual BGP attribute to remember, and the order in which BGP considers attributes, and what attributes even are... and a lot more! As with any other Cisco topic, we have to walk before we can run. Let's take a look at what attributes are and what they do in BGP.

BGP attributes are much like what metrics are to OSPF, RIP, IGRP, and EIGRP. You won't see them listed in a routing table, but attributes are what BGP considers when choosing the best path to a destination when multiple valid (loop-free) paths exist.

When BGP has to decide between such paths, there is an order in which BGP considers the path attributes. For success on the CCNP exams, you need to know this order. BGP looks at path attributes in this order:

Highest weight (Cisco-proprietary BGP value)

Highest local preference (LOCAL_PREF)

Prefer locally originated route.

Shortest AS_PATH is preferred.

Choose route with lowest origin code. Internal paths are preferred over external paths, and external paths are preferred over paths with an origin of "incomplete".
Lowest multi-exit discriminator (MED)

External BGP routes preferred over Internal BGP routes.

If no external route, select path with lowest IGP cost to the next-hop router for iBGP.

Choose most recent route.

Choose lowest BGP RID (Router ID).

If you don't know what these values are, or how they're configured, don't panic! The next several parts of this BGP tutorial will explain it all. So spend some time studying this order, and in part II of this free BGP tutorial, we'll look at each of these values in detail. Keep studying!

CCNP Certification / BSCI Exam Tutorial: The BGP Neighbor Process

Like TCP, BGP is connection-oriented. An underlying connection between two BGP speakers is established before any routing information is exchanged. This connection takes place on TCP port 179. As with EIGRP and OSPF, keepalive messages are sent out by the BGP speakers in order to keep this relationship alive.

Once the connection is established, the BGP speakers exchange routes and synchronize their tables. After this initial exchange, a BGP speaker will only send further updates upon a change in the network topology.

The IGP protocols that use Autonomous Systems, IGRP and EIGRP, require prospective neighbors to be in the same AS. This is not true with BGP. Routers can be in different Autonomous Systems and still exchange routes. The BGP neighbors do not have to be directly connected, and often are not, but do need to be able to reach the IP addresses they use in their neighbor statements.

A BGP peer that is in the same AS is referred to as an Internal BGP (iBGP) Peer, where a BGP peer in another AS is an External BGP (eBGP) Peer.

A sample iBGP configuration:

Router bgp 100

Neighbor 10.1.1.2 remote-as 100


A sample eBGP configuration:

Router bgp 100

Neighbor 10.1.1.2 remote-as 200

Cisco recommends that eBGP peers be directly connected, where iBGP peers generally will not be.

Before we get too much farther into BGP theory, let’s get a configuration started. You’ll use the router bgp command to configure a router as a BGP speaker. Right after that, the neighbor command will be used to identify this BGP speaker’s potential neighbors. (The terms "peer" and "neighbor" are interchangeable in BGP, but it's the neighbor statement that is used to statically define neighbors. BGP is not capable of discovering neighbors dynamically.)

R1(config-router)#neighbor 172.12.123.3 remote-as 200

While almost all of the neighbor options are just that -- optional -- you do have to specify the BGP AS of the remote router. BGP has no mechanism to dynamically discover neighbors. Remember, BGP speakers do not have to be in the same AS to become peers. To verify that the remote BGP speaker has become a peer, run show ip bgp neighbor.


R1#show ip bgp neighbor

BGP neighbor is 172.12.123.3, remote AS 200, external link

BGP version 4, remote router ID 0.0.0.0

BGP state = Active

Last read 00:01:39, hold time is 180, keepalive interval is 60 seconds

Received 0 messages, 0 notifications, 0 in queue

Sent 0 messages, 0 notifications, 0 in queue

Route refresh request: received 0, sent 0

Default minimum time between advertisement runs is 30 seconds

The output here can be a little misleading the first time you read it. The first highlighted line shows 172.12.123.3 is a BGP neighbor, is located in AS 200, and is an external link, indicating that the neighbor is in another AS entirely. The second highlighted line shows the BGP state as Active. This sounds great, but it actually means that a BGP peer connection does not yet exist with the prospective neighbor.

So even though the show ip bgp neighbor output indicated that this is an Active neighbor relationship, that’s not as good as it sounds. Of course, the reason the peer relationship hasn’t been established is that we haven’t configured R3 yet!


R3(config)#router bgp 200
R3(config-router)#neighbor 172.12.123.1 remote-as 100

Verify the peer establishment with show ip bgp neighbor:

R3#show ip bgp neighbor

BGP neighbor is 172.12.123.1, remote AS 100, external link

BGP version 4, remote router ID 172.12.123.1

BGP state = Established, up for 00:01:18

Last read 00:00:17, hold time is 180, keepalive interval is 60 seconds

Local host: 172.12.123.3, Local port: 179 (BGP uses TCP Port 179)

Foreign host: 172.12.123.1, Foreign port: 11007
The peer relationship between R1 and R3 has been established.

Now that you know how the neighbor relationship itself is built, you need to start learning the many options of the neighbor command. You’ll have to master these to become a CCNP and CCIE!