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!
Showing posts with label metric. Show all posts
Showing posts with label metric. Show all posts
Thursday, December 25, 2008
Cisco CCNP / BSCI Certification: Route Redistribution And The Seed Metric
In the first part of this free CCNP / BSCI tutorial, we looked at how leaving one simple word out of our route redistribution configuration - "subnets" - resulted in an incomplete routing table when redistributing routes from RIP to OSPF. (If you missed that part of the tutorial, visit my website's "Free Tutorials" section.) Today, we'll look at redistributing OSPF routes into RIP and identify another common redistribution error.
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!
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!
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.
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.
Wednesday, December 24, 2008
Cisco CCNA Certification Exam Tutorial: Variance And Unequal Cost Load Balancing
To pass the CCNA exam, you've got to know how to work with IGRP and EIGRP unequal-cost load balancing. You may not see much IGRP in production networks anymore, but you'll see a lot of EIGRP, and part of fine-tuning your EIGRP network is making sure that all paths are in use while allowing for varying bandwidth rates.
Using the variance command is the easy part - it's getting the metric that's the hard part with IGRP. With EIGRP, you just look in the topology table and that's it. With IGRP, you've got to run a debug to get the right metric.
The variance command is a multiplier when the value supplied with the variance command is multiplied by the lowest-cost metric, it must exceed the higher-cost metric in order for the higher-cost route to be added.
If that sounds complicated, it's not. It's one of those things that sounds difficult, but isn't. Trust me!
In this example, R1 has two paths to 172.23.0.0, but is currently using only one. By looking in the IP routing table, we've seen that the lowest-cost metric for network 172.23.0.0 on R1 is 8576. This path goes through the 172.12.123.0 network. There is another valid path that uses the 172.12.13.0 network, but is not currently in use.
I 172.23.0.0/16 [100/8576] via 172.12.123.2, 00:00:53, Serial0
IGRP does not have a “show" command that displays all valid routes to a destination, as does EIGRP. The command debug ip igrp transactions will show the current metric of the routes using the 512 KBPS route.
R1#debug ip igrp transactions
IGRP protocol debugging is on
19:17:51: IGRP: broadcasting request on Loopback0
19:17:51: IGRP: broadcasting request on Serial0
19:17:51: IGRP: broadcasting request on Serial1
19:17:51: IGRP: received update from 172.12.13.3 on Serial1
19:17:51: subnet 172.12.13.0, metric 23531 (neighbor 21531)
19:17:51: subnet 172.12.123.0, metric 23531 (neighbor 8476)
19:17:51: network 1.0.0.0, metric 24031 (neighbor 8976)
19:17:51: network 2.0.0.0, metric 22131 (neighbor 1600)
19:17:51: network 3.0.0.0, metric 22031 (neighbor 501)
19:17:51: network 172.23.0.0, metric 21631 (neighbor 1100)
R1(config)#router igrp 1
R1(config-router)#variance 3
R1#show ip route 172.23.0.0
Routing entry for 172.23.0.0/16
Known via "igrp 1", distance 100, metric 8576
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 172.12.123.2 on Serial0, 00:00:01 ago
Routing Descriptor Blocks:
* 172.12.13.3, from 172.12.13.3, 00:00:20 ago, via Serial1
Route metric is 21631, traffic share count is 1
Total delay is 21000 microseconds, minimum bandwidth is 512 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0
172.12.123.3, from 172.12.123.3, 00:00:20 ago, via Serial0
Route metric is 8576, traffic share count is 3
Total delay is 21000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0
172.12.123.2, from 172.12.123.2, 00:00:01 ago, via Serial0
Route metric is 8576, traffic share count is 3
Total delay is 21000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0
The metric for 172.23.0.0 through the direct connection is 21631. A variance of 3 means that any route with a metric less than the best metric multiplied by the variance (in this case, 8576 x 3 = 25728) will be entered into the routing table. R1 now has three unequal-cost paths to 172.23.0.0 in its routing table, and load balancing will take place.
IGRP unequal-cost load balancing takes some practice, but as you can see, once you get the metric it's easy to work with. Just make sure you know how to get that metric!
Using the variance command is the easy part - it's getting the metric that's the hard part with IGRP. With EIGRP, you just look in the topology table and that's it. With IGRP, you've got to run a debug to get the right metric.
The variance command is a multiplier when the value supplied with the variance command is multiplied by the lowest-cost metric, it must exceed the higher-cost metric in order for the higher-cost route to be added.
If that sounds complicated, it's not. It's one of those things that sounds difficult, but isn't. Trust me!
In this example, R1 has two paths to 172.23.0.0, but is currently using only one. By looking in the IP routing table, we've seen that the lowest-cost metric for network 172.23.0.0 on R1 is 8576. This path goes through the 172.12.123.0 network. There is another valid path that uses the 172.12.13.0 network, but is not currently in use.
I 172.23.0.0/16 [100/8576] via 172.12.123.2, 00:00:53, Serial0
IGRP does not have a “show" command that displays all valid routes to a destination, as does EIGRP. The command debug ip igrp transactions will show the current metric of the routes using the 512 KBPS route.
R1#debug ip igrp transactions
IGRP protocol debugging is on
19:17:51: IGRP: broadcasting request on Loopback0
19:17:51: IGRP: broadcasting request on Serial0
19:17:51: IGRP: broadcasting request on Serial1
19:17:51: IGRP: received update from 172.12.13.3 on Serial1
19:17:51: subnet 172.12.13.0, metric 23531 (neighbor 21531)
19:17:51: subnet 172.12.123.0, metric 23531 (neighbor 8476)
19:17:51: network 1.0.0.0, metric 24031 (neighbor 8976)
19:17:51: network 2.0.0.0, metric 22131 (neighbor 1600)
19:17:51: network 3.0.0.0, metric 22031 (neighbor 501)
19:17:51: network 172.23.0.0, metric 21631 (neighbor 1100)
R1(config)#router igrp 1
R1(config-router)#variance 3
R1#show ip route 172.23.0.0
Routing entry for 172.23.0.0/16
Known via "igrp 1", distance 100, metric 8576
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 172.12.123.2 on Serial0, 00:00:01 ago
Routing Descriptor Blocks:
* 172.12.13.3, from 172.12.13.3, 00:00:20 ago, via Serial1
Route metric is 21631, traffic share count is 1
Total delay is 21000 microseconds, minimum bandwidth is 512 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0
172.12.123.3, from 172.12.123.3, 00:00:20 ago, via Serial0
Route metric is 8576, traffic share count is 3
Total delay is 21000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0
172.12.123.2, from 172.12.123.2, 00:00:01 ago, via Serial0
Route metric is 8576, traffic share count is 3
Total delay is 21000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0
The metric for 172.23.0.0 through the direct connection is 21631. A variance of 3 means that any route with a metric less than the best metric multiplied by the variance (in this case, 8576 x 3 = 25728) will be entered into the routing table. R1 now has three unequal-cost paths to 172.23.0.0 in its routing table, and load balancing will take place.
IGRP unequal-cost load balancing takes some practice, but as you can see, once you get the metric it's easy to work with. Just make sure you know how to get that metric!
Subscribe to:
Posts (Atom)
