Microsoft developed this type of training to allow individuals to get a specific training course, or several in various types of skills that pertain to Microsoft. The thing about this training is that it is specific to Microsoft. While you may learn to install a program in another course which would teach a broad range of information about all ways in which to do so, in the MSCE, you will learn strictly how it is done through Microsoft.

So, How Does MSCE Work?

In most cases, the training can be done in several ways. Students can take classes through certified teachers in school or they can study on their own. Some individuals feel that they have enough experience in the various uses of Microsoft to be able to take the test without taking a training class. The test is given at specific areas at specific times. In order to be considered, you must pay a fee of about $125 for each of the tests and certifications that you plan to take. The tests range in knowledge levels and in most cases, it is wise to take the training courses for MSCE prior to taking the test as it can be quite challenging.

You will find more information about MSCE throughout the web.

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.

We are using a three-router network. R5 is running RIP, R1 is serving as a hub between R5 and R3 and is running RIP and OSPF, and R3 is running OSPF.

To begin this lab, we’ll add three loopbacks to R3 and advertise them to R1 via OSPF.

R3(config)#int loopback33

R3(config-if)#ip address 33.3.3.3 255.255.255.255

R3(config-if)#int loopback34

R3(config-if)#ip address 34.3.3.3 255.255.255.255

R3(config-if)#int loopback35

R3(config-if)#ip address 35.3.3.3 255.255.255.255

R3(config-if)#router ospf 1

R3(config-router)#network 33.3.3.3 0.0.0.0 area 1

R3(config-router)#network 34.3.3.3 0.0.0.0 area 1

R3(config-router)#network 35.3.3.3 0.0.0.0 area 1

R1 sees all three of these routes in its routing table.

R1#show ip route ospf

34.0.0.0/32 is subnetted, 1 subnets

O IA 34.3.3.3 [110/65] via 172.12.123.3, 00:00:55, Serial0

35.0.0.0/32 is subnetted, 1 subnets

O IA 35.3.3.3 [110/65] via 172.12.123.3, 00:00:45, Serial0

33.0.0.0/32 is subnetted, 1 subnets

O IA 33.3.3.3 [110/65] via 172.12.123.3, 00:00:55, Serial0

We’ll now redistribute these routes into RIP on R1. Remember the “subnets” option we talked about in the first part of this tutorial? There is no such option when redistributing OSPF routes into RIP, as IOS Help shows us.

R1(config)#router rip

R1(config-router)#redistribute ospf 1 ?

match Redistribution of OSPF routes

metric Metric for redistributed routes

route-map Route map reference

vrf VPN Routing/Forwarding Instance

R1(config-router)#redistribute ospf 1

The routes have been redistributed into RIP with the redistribute ospf 1 command. (The “1″ is the OSPF process number.) Let’s look at R5 and see the results.

R5#show ip route rip

R5#

The routes aren’t there, but we didn’t get a warning from the router that we needed to do anything else. What is the problem?

The problem is that RIP requires a seed metric to be specified when redistributing routes into that protocol. A seed metric is a “starter metric” that gives the RIP process a metric it can work with. The OSPF metric of cost is incomprehensible to RIP, since RIP’s sole metric is hop count. We’ve got to give RIP a metric it understands when redistributing routes into that protocol, so let’s go back to R1 and do so.

R1(config)#router rip

R1(config-router)#no redistribute ospf 1

R1(config-router)#redistribute ospf 1 metric 2

R5 now sees the routes. Note that the metric contained in the brackets is the seed metric.

R5#show ip route rip

34.0.0.0/32 is subnetted, 1 subnets

R 34.3.3.3 [120/2] via 100.1.1.1, 00:00:24, Ethernet0

35.0.0.0/32 is subnetted, 1 subnets

R 35.3.3.3 [120/2] via 100.1.1.1, 00:00:24, Ethernet0

33.0.0.0/32 is subnetted, 1 subnets

R 33.3.3.3 [120/2] via 100.1.1.1, 00:00:24, Ethernet0

If you read the previous tutorial, you may have noticed that we did not specify a seed metric for OSPF. OSPF does not require a seed metric to be set during redistribution. You also noticed that the router did tell us that there might be a problem when we left the “subnets” option out of RIP>OSPF redistribution, but the router didn’t tell us anything about a seed metric when we performed OSPF>RIP redistribution. This is a detail you must know by heart in order to make your route redistribution successful!

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.

One of the major differences between OSPF and ISIS will be evident to you when you first begin your BSCI exam studies, and that is the terminology. ISIS uses terms that no other protocol you’ve studied to date uses, and learning these new terms is the first step to BSCI and CCNP exam success.

First off, what does “IS” stand for in “ISIS”? It stands for “Intermediate System”, which sounds like a group of routers. As opposed to Autonomous Systems, which are logical groups of routers, an Intermediate System is simply a single router. That’s it.

You’ll also become familiar with End Systems, referred to in ISIS as an “ES”. The End System is simply an end host.

ISIS and OSPF both use the concept of areas, but ISIS takes a different approach to this concept. ISIS routers use three different types of routing levels, according to the area a router has been placed in. Level 2 routers are connected only to the backbone and serve as a transit device between non-backbone areas. Level 1 routers are totally internal to a non-backbone area.

ISIS uses both Level-1 and Level-2 Hellos, meaning that the two types of routers just mentioned cannot form an adjacency. Luckily for us, there is a middle ground, and that is the Level 1-2 router. These routers connect non-backbone areas to backbone areas. L1-L2 routers keep two separate routing tables, one for L1 routing and another for L2 routing. This is the default setting for a Cisco router, and L1-L2 routers can form adjacencies with both L1 and L2 routers.

Part of the challenge of learning ISIS is getting used to the differences between ISIS and OSPF. Keep studying the terminology, master one concept at a time, and soon you’ll be a master of ISIS and a CCNP to boot!

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.

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.