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.
Showing posts with label path. Show all posts
Showing posts with label path. Show all posts
Thursday, December 25, 2008
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!
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 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.
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 / BCMSN Exam Tutorial: Multicasting And The RPF Check
Multicasting is a vital topic on your BCMSN, CCNP, and CCIE exams, and it can also be very confusing when you first start studying it. Multicasting uses concepts that are unlike anything you've run into in your routing protocol studies, and that can throw you at first. I speak from experience that multicasting is like any other Cisco technology - learn the basics, master the fundamentals, and then build your skills on that foundation.
One such fundamental is the RPF Check, or Reverse Path Forwarding Check.
A fundamental difference between unicasting and multicasting is that a unicast is routed by sending it toward the destination, while a multicast is routed by sending it away from its source.
"toward the destination" and "away from its source" sound like the same thing, but they're not. A unicast is going to follow a single path from source to destination. The only factor the routers care about is the destination IP address - the source IP address isn't a factor.
With multicast routing, the destination is a multicast IP group address. It's the multicast router's job to decide which paths will lead back to the source (upstream) and which paths are downstream from the source. Reverse Path Forwarding refers to the router's behavior of sending multicast packets away from the source rather than toward a specific destination.
The RPF Check is run against any incoming multicast packet. The multicast router examines the interface that the packet arrived on. If the packet comes in on an upstream interface - that is, an interface found on the reverse path that leads back to the source - the packet passes the check and will be forwarded. If the packet comes in on any other interface, the packet is dropped.
The RPF Check serves to verify the integrity of your multicasting network, and also serves as a reminder that the basic operation of multicasting is a lot different than unicasting!
One such fundamental is the RPF Check, or Reverse Path Forwarding Check.
A fundamental difference between unicasting and multicasting is that a unicast is routed by sending it toward the destination, while a multicast is routed by sending it away from its source.
"toward the destination" and "away from its source" sound like the same thing, but they're not. A unicast is going to follow a single path from source to destination. The only factor the routers care about is the destination IP address - the source IP address isn't a factor.
With multicast routing, the destination is a multicast IP group address. It's the multicast router's job to decide which paths will lead back to the source (upstream) and which paths are downstream from the source. Reverse Path Forwarding refers to the router's behavior of sending multicast packets away from the source rather than toward a specific destination.
The RPF Check is run against any incoming multicast packet. The multicast router examines the interface that the packet arrived on. If the packet comes in on an upstream interface - that is, an interface found on the reverse path that leads back to the source - the packet passes the check and will be forwarded. If the packet comes in on any other interface, the packet is dropped.
The RPF Check serves to verify the integrity of your multicasting network, and also serves as a reminder that the basic operation of multicasting is a lot different than unicasting!
Subscribe to:
Posts (Atom)
