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 CCNA Exam Tutorial: Five OSPF Hub-And-Spoke Details You Must Know!

CCNA exam success depends greatly on knowing the details, and if there's one protocol that has a lot of details, it's OSPF! This is true particularly of hub-and-spoke networks, so in this CCNA OSPF tutorial we'll take a look at some of the more important hub-and-spoke OSPF details. This will help you in working with real-world networks as well, since this OSPF network type is one of the more typical network topologies.

In OSPF, the hub must become the designated router (DR). The DR election's deciding value is the OSPF interface priority, and the default value is 1. It's not enough to set the hub's OSPF interface to 2, however, since the spoke routers must not become the DR or BDR. You must set the spoke interfaces to an OSPF priority of zero.

R2(config)#int s0

R2(config-if)#ip ospf priority 0

This ensures that the spokes will not become the DR or BDR if the hub goes down.

The hub does require a bit more configuration, though. The neighbor command must be used on the hub to indicate the IP address of the potential neighbors.

R1(config)#router ospf 1

R1(config-router)#neighbor 172.12.123.2

R1(config-router)#neighbor 172.12.123.3

It's common to have an ISDN link as a backup in an OSPF network, and when that ISDN link comes up the hello packets must be able to cross the link. What you don't want is to have the hellos keep the link up! By configuring the ISDN link as an OSPF demand circuit, the link will drop in the absence of interesting traffic, but the OSPF adjacency that formed across the ISDN link will be assumed by the router to still be up. (You usually see this command configured on both sides of the ISDN link, but it's only needed on one side. It doesn't hurt anything to put it on both sides, though.)

R2(config)#int bri0

R2(config-if)#ip ospf demand-circuit

A final detail of OSPF hub-and-spoke and demand circuits actually takes place at Layer 2. For the OSPF hello packets to successfully be transmitted across an ISDN link or a frame relay network, the broadcast option must be enabled in the appropriate frame and dialer map statements. Failure to enable this option can lead to a situation where pings will be successful, but OSPF adjacencies will not form.

R2(config-if)#dialer map ip 172.12.21.1 name R1 broadcast 5551111

R2(config-if)#frame map ip 172.12.123.1 221 broadcast

When you're troubleshooting OSPF in a production network or your CCNA / CCNP home lab, don't just look at Layer 3 - because everything's got to be right at the physical and data link layers in order for the network layer to function correctly!

Cisco CCNA Certification Exam Tutorial: OSPF Hub-And-Spoke

CCNA certification demands that you master the basics of OSPF, and for many studying for the CCNA exam, their first exposure to OSPF is a hub-and-spoke configuration. That's a tough way to get started, because a hub-and-spoke configuration built over an NBMA technology such as Frame Relay requires quite a bit of attention to detail. Let's take a quick look at several common OSPF configuration errors and how to avoid them on your CCNA test.

Make sure the hub is the designated router and that there are no backup designated routers. This is done by setting the OSPF interface priority to zero on the spoke routers. This not only ensures that the hub wins the DR election with its default OSPF interface priority of 1, but it prevents the spokes from ever having a chance to become the DR or BDR.

Configure neighbor statements on the hub. Since we're dealing with an NBMA network, the hub cannot dynamically discover its neighbors. Neighbor statements are not needed on the spokes. (They don't hurt anything, but they don't do anything, either.)

Finally, if your OSPF adjacencies do not form as expected, make sure to use your OSI model knowledge to approach the problem. The issue may actually be at Layer Two, with your Frame Relay configuration. If you don't use the "broadcast" option on your frame relay statements, OSPF hellos will not be transmitted successfully between potential neighbors. OSPF hellos are multicast, but the "broadcast" option for Frame Relay includes multicasts.

By paying special attention to these details, you're that much close to CCNA exam day success and earning your certification. I recommend that you get some experience with configuring OSPF hub-and-spoke before taking the CCNA exam, because it’s by actually performing tasks such as this that makes you supremely confident on CCNA test day.

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!